Synch with skeleton v0.0.5-r2

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> [Standardisation request M/606 - C\(2025\)618](https://ec.europa.eu/growth/tools-databases/enorm/mandate/606_en): "Commission Implementing decision of 3.2.2025 on a 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/1020and Directive (EU) 2020/1828 (Cyber Resilience Act)".

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> prEN 40000-1-1: "Cybersecurity requirements for products with digital elements - Vocabulary"

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> prEN 40000-1-1: "Cybersecurity requirements for products with digital elements – Vocabulary"

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> prEN 40000-1-2: “Cybersecurity requirements for products with digital elements – Principles for cyber resilience”

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> prEN 40000-1-2: "Cybersecurity requirements for products with digital elements – Part 1-2: Principles, product risk management, and lifecycle activities”

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> EU 2024/2847 "Cyber Resilience Act"

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a>	prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Part 1-3: Vulnerability handling“

<span id="_ref_i.7"></span><a name="_ref_i.6">[i.7]</a>	prEN 40000-1-4: "Cybersecurity requirements for products with digital elements – Part 1-4:  Security controls – Generic security requirements”

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> ETSI EN 304 XXX IAM (CEN/TC 224 WG 17 output)

<span id="_ref_i.13"></span><a name="_ref_i.13">[i.13]</a> NIST SP 800-63B-4 Authentication & Authenticator Management

<span id="_ref_i.14"></span><a name="_ref_i.14">[i.14]</a> prEN 40000-1-1 "Vocabulary"

<span id="_ref_i.15"></span><a name="_ref_i.15">[i.15]</a> prEN 40000-1-2 "Principles for cyber resilience"

<span id="_ref_i.16"></span><a name="_ref_i.16">[i.16]</a> Directive (EU) 2022/2555 of the European Parliament and the council and (EU) 2024/2690 European Commission implementing regulation

<span id="_ref_i.17"></span><a name="_ref_i.17">[i.17]</a> Example source for DDoS related threat reports https://radar.cloudflare.com/reports

For the purposes of the present document, the terms given in Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1), prEN 40000-1-1 [\[i.4\]](#_ref_i.4) and the following apply:

<mark>Editor’s Note: The standard should not do legal interpretation by defining some key legal concepts of Regulation (EU) 2024/2847. Notably, the standard should not define “core functionality” or “due diligence”.</mark>

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

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

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

<mark>This could be about how wireguard nodes are configured manually and how they form the routing infrastructure extending to tailscale. Similar setup to VPN.</mark>

### 4.3.5 Trust initialisation

### 4.3.4 Connectivity aspects

### 4.3.x Trust initialisation

To initialize trust between the elements of the network, this type of NMS multiple can use multiple methods including but not limited to: identity confirming certificates, unique serial numbers, or stored credentials, usually in the form of pre-installed keys.

These credentials are used during initialisation to create the trust between the NMS, the networked devices and, if present, with the IoT device business logic.

Independent of any of the host system's capabilities, the NMS can also be remotely accessible.

### 4.3.6 Risk management

### 4.3.x Risk management

Key areas to understand when determining how an IoT network management system can affect customers' operations comes from understanding how enrollment works, how isolated the control systems are, how large pools of devices are managed, and what the device is designed to do.

These variations are determined by the nature of the IoT network, meaning that the appropriate NMS may require different security features depending on the security needs of its operational environment and users as well as functions.

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

## 5.11 Impact minimisation

## 5.11 Non-interference

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

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

## 5.12 Minimisation of attack surfaces

## 5.12 Attack surface minimisation

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

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

## 5.13 Exploitation mitigation mechanisms

## 5.13 Exploit mitigation

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

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

## 5.14 Logging and monitoring

## 5.14 Monitoring

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

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

## 5.15 Data removal and transparency

## 5.15 Factory reset and data portability

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

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

## 5.16 Vulnerability handling

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

The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be fulfilled for the product.

# 6 Assessment criteria for compliance with technical requirements

<mark>Editor’s Note: It has been agreed across vertical standards to define each assessment criteria following the common structure:<br>

    - Activities<br>

    - Verdict<br>

    - Evidence<br>

The assessment criteria clause shall be structured by requirement defined in clause 5.

</mark>

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

* **Assessment reference:** Refers to the identifier of the concerned technical requirement.

* <mark>Editor’s Note: Ideally, the reference is formatted also as a link to the corresponding technical requirement clause, allowing readers to jump to that section (and back).</mark>

* **Assessment reference:** Refers to the identifier of the concerned technical requirement.\

  <mark>Editor’s Note: Ideally, the reference is formatted also as a link to the corresponding technical requirement clause, allowing readers to jump to that section (and back).</mark>

* **Assessment objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

* **Assessment preparation:** Describes the environment, setup, and preconditions required before executing the test with a view to guaranteeing consistent evaluation results. It includes the following elements as applicable:

  * Test environment: Describe the hardware, software, and network setup used for the assessment, including versions, topology, and any relevant dependencies.

  * Preconditions: Specify any configurations, credentials, or operational states that should be established before the test (e.g. product initialized, certificates loaded, user roles created).

  * Required tools: Identify the tools or software necessary to perform the assessment (e.g. vulnerability scanners, protocol fuzzers, traffic analysers, static code analysers, cryptographic test suites).

  * <mark>Editor’s Note: Precisely reference individual tools or include an unambiguous characterisation by way of tool capabilities to ensure consistent tool application. For instance, “state-of-the-art vulnerability scanner” shall instead be replaced with “vulnerability scanner that covers all CVEs, supports credentialed and non-credentialed scans, ...”</mark>

  * <mark>Editor’s Note: The standard shall not discourage the use of paid security products to comply with requirements by mandating specific free tools where other options are equally suitable. In such cases, the free tools can be listed informatively, but the general capabilities required of the tool should be listed normatively.</mark>

  * Required tools: Identify the tools or software necessary to perform the assessment (e.g. vulnerability scanners, protocol fuzzers, traffic analysers, static code analysers, cryptographic test suites).\

  <mark>Editor’s Note: Precisely reference individual tools or include an unambiguous characterisation by way of tool capabilities to ensure consistent tool application. For instance, “state-of-the-art vulnerability scanner” shall instead be replaced with “vulnerability scanner that covers all CVEs, supports credentialed and non-credentialed scans, ...”</mark>\

  <mark>Editor’s Note: The standard shall not discourage the use of paid security products to comply with requirements by mandating specific free tools where other options are equally suitable. In such cases, the free tools can be listed informatively, but the general capabilities required of the tool should be listed normatively.</mark>

  * Required information/documentation for the assessment: Specify all information that is necessary to perform the assessment.

  * Reference any vendor‑provided setup guides, configuration instructions, or operational manuals, as well as any relevant standards or technical notes, that define how the product shall be configured or operated for the assessment.

* **Assessment activities:** Provides execution steps to be performed such that the same assessment verdict would be reached when repeating these steps now or at a later point in time. Assessment activities may include, as applicable:

  * Review information/documentation for the assessment to confirm that the described implementation matches the requirement (e.g. verify that the security architecture document specifies TLS 1.2 or higher for all external interfaces, or that the password policy aligns with the defined threshold).

  * <mark>Editor’s Note: Checking documentation for the presence or absence of certain security controls should be the last resort or only a supporting activity, with strong preference given to actual verification of security qualities of the product by testing the final product or its source code.</mark>

  * Review information/documentation for the assessment to confirm that the described implementation matches the requirement (e.g. verify that the security architecture document specifies TLS 1.2 or higher for all external interfaces, or that the password policy aligns with the defined threshold).\

  <mark>Editor’s Note: Checking documentation for the presence or absence of certain security controls should be the last resort or only a supporting activity, with strong preference given to actual verification of security qualities of the product by testing the final product or its source code.</mark>

  * Perform security functional tests to verify the completeness and correctness of the information/documentation for the assessment.

  * Perform security functional or penetration tests to verify that implemented controls are correctly implemented e.g. to prevent unauthorized access or data modification (e.g. via attempting to log in with invalid credentials to test lockout enforcement or trying to modify protected configuration files without administrative privileges).

  * Analyse code or binaries to identify potential security weaknesses or misconfigurations (e.g. perform static analysis to detect hardcoded credentials or use dynamic analysis tools to identify buffer overflow or injection vulnerabilities).

Once the present document is cited in the Official Journal of the European Union under Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1), conformance with the normative clauses of the present document given in the tables in Annex A confers, to products with digital elements in the scope of the present document, a presumption of conformity with the corresponding essential requirements of that Regulation and associated EFTA regulations.

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

**Table A.1: Relationship between the present document and the requirements of Regulation (EU) 2024/2847 - the Cyber Resilience Act**<a name="table_A.1"></a>

| Description             | Clause(s) of the present document | U/C |

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

| Annex I, Part 1, (1)    | Clause 5                          | C   |

| Annex I, Part 1, (2)(a) | Clause 5.2                        | U/C |

| Annex I, Part 1, (2)(b) | Clause 5.3                        | U/C |

| Annex I, Part 1, (2)(c) | Clause 5.4                        | U/C |

| Annex I, Part 1, (2)(d) | Clause 5.5                        | U/C |

| Annex I, Part 1, (2)(e) | Clause 5.6                        | U/C |

| Annex I, Part 1, (2)(f) | Clause 5.7                        | U/C |

| Annex I, Part 1, (2)(g) | Clause 5.8                        | U/C |

| Annex I, Part 1, (2)(h) | Clause 5.9                        | U/C |

| Annex I, Part 1, (2)(i) | Clause 5.10                       | U/C |

| Annex I, Part 1, (2)(j) | Clause 5.11                       | U/C |

| Annex I, Part 1, (2)(k) | Clause 5.12                       | U/C |

| Annex I, Part 1, (2)(l) | Clause 5.13                       | U/C |

| Annex I, Part 1, (2)(m) | Clause 5.14                       | U/C |

| Annex I, Part 2         | Clause 5.15                       | U   |

| Annex I, Part 1, (1)    | Clause 5.2                          | C   |

| Annex I, Part 1, (2)(a) | Clause 5.3                        | U/C |

| Annex I, Part 1, (2)(b) | Clause 5.4                        | U/C |

| Annex I, Part 1, (2)(c) | Clause 5.5                        | U/C |

| Annex I, Part 1, (2)(d) | Clause 5.6                        | U/C |

| Annex I, Part 1, (2)(e) | Clause 5.7                        | U/C |

| Annex I, Part 1, (2)(f) | Clause 5.8                        | U/C |

| Annex I, Part 1, (2)(g) | Clause 5.9                        | U/C |

| Annex I, Part 1, (2)(h) | Clause 5.10                        | U/C |

| Annex I, Part 1, (2)(i) | Clause 5.11                       | U/C |

| Annex I, Part 1, (2)(j) | Clause 5.12                       | U/C |

| Annex I, Part 1, (2)(k) | Clause 5.13                       | U/C |

| Annex I, Part 1, (2)(l) | Clause 5.14                       | U/C |

| Annex I, Part 1, (2)(m) | Clause 5.15                       | U/C |

> NOTE 1: The table cannot indicate direct relationship between the relevant legal requirement and **_other_** standards or normative clauses contained in **_other_** standards.

## R.6 Mapping of CRA Annex I to Annex R requirements

# History

# Annex L (informative): Change history

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