### 5.3.2 Mitigations for ingested data integrity and confidentiality
### 5.3.3 Mitigations for managed device configuration integrity and confidentiality
### 5.3.4 Secure updates
### 5.3.5 Logging
### 5.3.6 Metrics
### 5.3.7 Data minimisation
### 5.3.8 High Availability
# 6 Conformity assessments and tests
## 6.1 General requirements assessments
### 6.1.1 No known exploited vulnerabilities tests
## 6.2 Technical cybersecurity requirement tests and assessments
## 6.3 Risk mitigations tests
### 6.3.5 Logging tests
### 6.3.8 High availability tests
# Annex A (informative): Mapping with essential requirements of the CRA
> Table mapping technical cybersecurity 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 cybersecurity requirements.
| Authentication and access control mechanisms | [5.2.6 Role based authorisation](#526-role-based-authorisation) |
| Confidentiality protection | [5.3.2 Mitigations for ingested data integrity and confidentiality](#532-mitigations-for-ingested-data-integrity-and-confidentiality) |
| Integrity protection for data and configuration | [5.3.2](#532-mitigations-for-ingested-data-integrity-and-confidentiality), [5.3.3](#533-mitigations-for-managed-device-configuration-integrity-and-confidentiality), [5.3.6 Metrics](#536-metrics) |
| Data minimisation | [5.3.7 Data minimisation](#537-data-minimisation) |
| Availability protection | [5.3.8 High Availability](#538-high-availability) |
| Minimise impact on other devices or services | [5.3.8 High Availability](#538-high-availability) |
# Annex C (informative): Risk acceptance criteria and risk management methodology
> Ref. (PT1 6.3)
> Table mapping the identified risks to requirements
## C.1 Risk acceptance and risk management methodology
> Describe how to decide if residual risks are tolerable.
## C.2 Risk assessment methodology
Risk levels for each factors are determined by reading the descriptions for each risk factor and choosing the one that most accurately represents the highest risk for the intended purpose and reasonably foreseeable use and misuse of the product, as specified by the product.
The risks can be divided to likelihood and impact, but they can also be presented as a whole.
When likelihood and impact is presented, only high and low evaluation is available.
Risk is considered to be medium, when one of the likelihood and impact is low, and the other one is high.
When both likelihood and impact are low, the requirements defined in the chapter [5 Requirements specifications] defined for low category sets the minimum required features for any product within the category subject to this document.
When multiple risk factors are combined in a single requirement applicability, the highest risk level determines what is required from the product.
To be able to map the product requirements applicability:
1. Document a comprehensive range of foreseeable use cases for products of this type.
1. Define the product risk levels evaluating the risk factors as low-mid-high based on the instructions.
1. Cross reference to [5 Requirements specifications](#5-requirements-specifications) requirements.
1. See from [6 Conformity asssessments and tests](#6-conformity-assessments-and-tests) how to show conformity of the product.
## C.2.1 Assets
NMS protects systems that are relying on network connectivity to perform its daily operations.
### C.2.1.1 Data assets
## C.2.2 Threats
> Based on the assets, what are the threats during:
>
> - Use for intended purpose or reasonably foreseeable use
> - When integrated into another product
> Example threats can be found in the same documents suggested in the section on cybersecurity requirements.
[Recital 58] [\[i.1\]](#_ref_i.1)
- economic espionage
- irresponsible state behaviour in cyberspace and its legislation allows
- arbitrary access to any kind of company operations or data
- commercially sensitive data
- impose obligations for intelligence purposes without democratic checks and balances
- **Rationale:** A network management system requires a trustworthy operating system to perform its functions.
- [A-OS-L-1]: The operating system is assumed to be trustworthy.
- [A-OS-L-2]: The operating system provides and enforces process isolation
- Proper administrator
- **Rationale:** A network management system requires effective administration to perform its functions.
- [A-ADMIN-L-1]: The administrator is assumed to be trustworthy.
- [A-ADMIN-L-2]: The administrator is limited to protect against accidental misconfiguration.
- [A-ADMIN-L-3]: The administrator is severely limited to protect against intentional misconfiguration.
# Annex L (informative): Relationship between the present document and the requirements of EU Regulation 2024/2847
DRAFT ANNEX L - DO NOT CONSIDER THE CONTENT
The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 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) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).
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.
> NOTE: The above paragraphs have to be repeated in the Foreword.
The annex shall have a table for a clear indication of correspondence between normative clauses of the standard and the legal requirements aimed to be covered.
**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: **EXAMPLE for a table:**
**Table A.1: Relationship between the present document and the requirements of EU Regulation 2024/2847**<aname="#table_A.1"></a>
**No** A unique identifier for one row of the table which may be used to identify a requirement.
**Description** A textual reference to the requirement.
**Requirements of Regulation** Identification of article(s) defining the requirement in the Regulation.
**Clause(s) of the present document** Identification of clause(s) defining the requirement in the present document unless another document is referenced explicitly.
**Requirement Conditionality:**
**Use case** Indicates whether the requirement is unconditionally applicable (U) or is conditional upon the manufacturer's claimed functionality of the equipment (C).
**Condition** Explains the conditions when the requirement is or is not applicable for a requirement which is classified "conditional".
> NOTE 1: The table cannot indicate direct relationship between the relevant legal requirement and other standards or normative clauses contained in other standards.
> NOTE 2: The order of the first and the second columns can be changed.
> NOTE 3: The title of this column can be adapted on the basis of specific needs
The annex shall have at least the following two warnings.
A warning stating that presumption of conformity is effective only as long as the reference is maintained in the OJEU by the Commission. The following URL-address [https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en](https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en) to consult the latest list of Harmonised Standards published in the OJEU should be provided.
Presumption of conformity stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal of the European Union. Users of the present document should consult frequently the latest list published in the Official Journal of the European Union.
A warning stating that those products or services which are within the scope of a relevant standard may be also subject to other Union legislation.
Other Union legislation may be applicable to the product(s) falling within the scope of the present document.
The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.
