@@ -113,9 +113,9 @@ The present document may include trademarks and/or tradenames which are asserted
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).
```
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).
```
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 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.
@@ -142,8 +142,6 @@ In the present document "**shall** ", "**shall not** ", "**should** ", "**should
This document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is as a 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 <ahref="#_ref_i.1">[i.1]</a>.
@@ -348,7 +346,6 @@ When the IoT device business logic user or the IoT device interracts with the sy
This example architecture can be used as a base when manufacturer demonstrates compatibility to CRA's <ahref="_ref_i.1">[i.1]</a> Annex I part 1 appropriate level of cybersecurity.
@@ -379,7 +376,7 @@ There can be multple devices in the same network, and the NMS provides supportin
- Large enterprice network
## 4.5 Risk factors
## 4.5 Risk Factors
For each network management system placed on the market, the manufacturer shall develop a threat model and risk profile of the forseeable use of the network management system, and shall consider the interplay between:
@@ -389,7 +386,7 @@ For each network management system placed on the market, the manufacturer shall
The security profile requirements reflects the intented deployment of the NMS.
### 4.5.1 List of risk factors
### 4.5.1 List of Risk Factors
The risk factors identified by the risk assessment in Annex C are grouped into risk categories and assigned unique identifiers below.
@@ -441,7 +438,7 @@ In case of overlap in the requirements, a stronger and more secure option shall
[4.4.2.2 Waste management]:#4422-waste-management
[4.4.2.3 Telecom network]:#4423-telecom-network
## 4.6 Security profiles
## 4.6 Security Profiles
### 4.6.1 General
@@ -461,7 +458,7 @@ Security profiles are associated with sets of risk factor levels.
| SEC-4 | | | |
| SEC-5 | | | |
## 4.7 Essential functions
## 4.7 Essential Functions
These essential functions lists, as an example, what the product does during it's intentent use, how it's functions are covered and how it keeps it self secure and functioning.
@@ -552,7 +549,6 @@ The metrics can be for example the last time when the managed element has been s
-**[RQ-9]**
-**[RQ-10]**
- Authenticate the source of updates (digital signatures).
- Verify integrity before installation (hash checks).
- Use secure channels for delivery (e.g., TLS).
@@ -565,7 +561,6 @@ The metrics can be for example the last time when the managed element has been s
> **TODO**: Connect the technical security requirements in Section 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in section 6.
# 6 Security Profiles
## 6.1 General
@@ -594,6 +589,7 @@ The metrics can be for example the last time when the managed element has been s
# 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.