Rename part 1

# Introduction

The present document is a European harmonised standard that defines cybersecurity requirements for products with digital elements whose primary purpose is connecting private networks with public networks or other private networks. 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.

The present document is a European harmonised standard that defines cybersecurity requirements for products with digital elements whose primary purpose is connecting private networks with public networks or other private networks. 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 <a href="#_ref_i.1">[i.1]</a>.

This standard does not apply to products that have VPN capabilities as a feature of a broader holistic networking or security product, though it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with VPNs.

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

* <a name="_ref_i.1">[i.1]</a>    &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

* <a name="_ref_i.0">[i.0]</a>    &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

* <a name="_ref_i.1">[i.1]</a>    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)

* <a name="_ref_i.2">[i.2]</a>    Commission Implementing Regulation (EU) TKTK TODO 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 (Text with EEA relevance)

# 4 Product context

## 4.1 Out of scope use/environments

## 4.2 Out of scope use/environments

The types of product with digital elements listed in the section do not fall within the scope of the the Regulation (EU) 2024/2847 (Cyber Resilience Act), and are not covered by this standard:

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a name="_ref_i.1">[i.1]</a>;

2. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a name="_ref_i.1">[i.1]</a>;

3. Products developed for or used exclusively for internal use by public administration as defined in CRA recital 16; article 5, 2 <a name="_ref_i.1">[i.1]</a>;

4. Non-commercial free and open source software as defined in CRA recitals 17-21; article 13, 5 <a name="_ref_i.1">[i.1]</a>;

5. Medical Devices and Software as defined in CRA recital 25; article 2, 2 [a-b] <a name="_ref_i.1">[i.1]</a>;

6. Vehicles, including aviation and marine equipment as defined in CRA recital 27; article 2, 2.c "vehicles"; recital 27; article 2, 3 "aviation"; article 2, 4 "marine equipment" <a name="_ref_i.1">[i.1]</a>;

7. Spare and used parts as defined in CRA recital 29; article 2, 6 <a name="_ref_i.1">[i.1]</a>;

8. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a name="_ref_i.1">[i.1]</a>;

1. Services, except for the remote data processing solutions for a covered product as defined in CRA recitals 11-12; article 3, 2 <a href="#_ref_i.1">[i.1]</a>;

2. Products specifically designed or procured for national security and defence purpose as defined in CRA recitals 14 and 26; article 2, 7-8 <a href="#_ref_i.1">[i.1]</a>;

3. Products developed for or used exclusively for internal use by public administration as defined in CRA recital 16; article 5, 2 <a href="#_ref_i.1">[i.1]</a>;

4. Non-commercial free and open source software as defined in CRA recitals 17-21; article 13, 5 <a href="#_ref_i.1">[i.1]</a>;

5. Medical Devices and Software as defined in CRA recital 25; article 2, 2 [a-b] <a href="#_ref_i.1">[i.1]</a>;

6. Vehicles, including aviation and marine equipment as defined in CRA recital 27; article 2, 2.c "vehicles"; recital 27; article 2, 3 "aviation"; article 2, 4 "marine equipment" <a href="#_ref_i.1">[i.1]</a>;

7. Spare and used parts as defined in CRA recital 29; article 2, 6 <a href="#_ref_i.1">[i.1]</a>;

8. Refurbished, repaired, and upgraded products that have not been substantially modifiedas defined in recitals 39 - 42 <a href="#_ref_i.1">[i.1]</a>;

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a name="_ref_i.1">[i.1]</a> and can only be partially covered by this standard.

The following types of products have reduced or varied requirements under Regulation (EU) 2024/2847 (Cyber Resilience Act) <a href="#_ref_i.1">[i.1]</a> and can only be partially covered by this standard.

9. High Risk AI as defined in CRA recital 51; article 12 <a name="_ref_i.1">[i.1]</a>;

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a name="_ref_i.1">[i.1]</a>;

11. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a name="_ref_i.1">[i.1]</a>.

9. High Risk AI as defined in CRA recital 51; article 12 <a href="#_ref_i.1">[i.1]</a>;

10. Testing and unfinished versions as defined in recital 37; Article 4, 2-3 <a href="#_ref_i.1">[i.1]</a>;

11. Products Placed on the Market Prior to December 11, 2027 as defined in CRA article 69 <a href="#_ref_i.1">[i.1]</a>.

## 4.2 Product overview and architecture

## 4.3 Product overview and architecture

> Explain the overall architecture and relationship among the parts of the products. Use diagrams if that is helpful.

#### 4.2.1 General

### 4.3.1 Product overview

As a holistic product, a Virtual Private Network includes, at mminimum, VPN client or software running in two or more locations which establish a secure encryptd tunnel to communicate. Most typically that involves VPN servers communicating with other VPN servers and/or VPN client software running on one or more endpoints.

As a holistic product, a Virtual Private Network includes, at minimum, VPN client or server software running in two or more locations which establish a secure encrypted tunnel to communicate. Most typically that involves VPN servers communicating with other VPN servers and/or VPN client software running on one or more endpoints.

### 4.2.2 Architecture

  - Software is typically preconfigured, providing limited opportunity for end user error in configuration

  - Carries significant risk due to its entrypoint into a private network

### 4.4.2 VPN software connecting data centres

### 4.4.3 VPN software connecting data centres

- [TK-B-1] Site-to-site VPN

  - Professionally administration by software developers or operations

  - Deployed to cloud data centres or on-prem data centres

  - Prioritises high throughput

### 4.4.3 VPN software intended for high-security enterprise

### 4.4.4 VPN software intended for high-security enterprise

- Financial institutions? Healthcare?

- TODO Graham Wallace

## 4.5 Security levels

## 4.5 Risk factors

_List the security levels and the use cases that correspond to them._

### 4.5.1 List of risk factors

### 4.5.1 Foo1

The risk factors identified by the risk assessment in Annex C are grouped into risk categories and assigned unique identifiers below.

This level of security applies to VPN products typically used at the enterprise level to connect non-geolocated internal networks to each other, and off-site employees to internal networks.

* Users with private network access

  * **[USR-L-0]** Restricted to few users with strong cybersecurity background

  * **[USR-L-1]** Restricted to devices fully managed by enterprise MDM

  * **[USR-L-2]** User-controlled hardware with a fully preconfigured VPN client 

  * **[USR-L-3]** User-controlled hardware with user-selected VPN client

* Users with administrative access

  * **[ADM-L-0]** Restricted to limited IT professionals with a physical presence on the private network

  * **[ADM-L-N]** TK a description of a scenario where the VPN is entirely cloud-based so admin _cannot_ have a physical presence

  * **[ADM-L-N]** Administrators can access VPN management portal via the VPN

* Physical access to data processing

  * **[PHY-L-N]** 

  * **[PHY-L-N]** 

  * **[PHY-L-N]** 

### 4.5.2 Bar1

Expected use-cases include Hospitals, financial institutions, high-risk individuals

## 4.6 Essential functions

### 4.5.1 Mapping of use cases to risk factors and security levels

## 4.6 Security levels

> List the security levels and the use cases that correspond to them.

Security levels are an informative resource to the manufacturer. Each security level is associated with a collection of levels of risk factors. Security levels will be mapped to the security requirements necessary to mitigate them in a future draft.

### 4.6.2 Mapping of security level to risk factors

Each security level will consist of the security requirements necessary to mitigate the threats related to the associated levels of risk factors.

> FIXME add security requirements when they exist

| Security level | Risk Factor Type 1 | Risk Factor Type 2 | Risk Factor Type 3 |

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

| TK-L1          |                    |                    |                    |

## 4.7 Essential functions

> List the essential functions of the product, including:

>

> - How its functions are configured?

> - How it keeps itself secure and functioning?

## 4.7 Operational Environment

## 4.8 Operational Environment

> Describe the expected operating environment given the exclusions in Section 4.2. This includes:

>

VPNs can be expected to operate in a network environment alongside other Important PwDEs such as Identity Access Management, Network Interfaces, Routers, and Firewalls. Manufacturers shall harden VPN attack surfaces against potential attack vectors from compromised PwDEs, but in particular those considered Important and Critical. See clause TK for further information about the relationship between VPNs and related software.

## 4.8 Users

## 4.9 Users

### 4.8.1 User Types and Descriptions

**USER-5**

: This user type is associated with individuals or organizations that are potential targets of sophisticated and high-resource adversaries. These users require a VPN product that provides the highest level of security and anonymity, and they are assumed to have advanced security knowledge to configure and manage the product's features.

## 4.10 Distribution of security functions

### 4.8.2 User Needs by Security Level (Pending Security Levels Definition)

#### 4.8.2.1 Overview

| Software Operations & Development | VPN software connecting data centres             | Critical Security |

| High-Risk & Advanced Users        | Commercial VPN service for high-risk targets     | Critical Security |

## 4.9 Risk distribution among components

## 4.10 Risk distribution among components

> Risk can be transferred between components, for example a network interface can document that secure update of its firmware must be handled by an external program, such as an operating system. In turn, the operating system can offer the security functionality of secure updates to other components in a system.

> Describe what risks are delegated to other components, as well as what security functionalities this product offers to things integrated with it.

## 4.10 Support period

## 4.11 Support period

> Describe the expected support period and its impact on security risks. Generally the support period should be at least 5 years, shorter or longer according to the expected period of use. See Article 13.8 and Recitals 59 - 62 of the CRA for more information.

> For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security levels.

> Guidance from latest PT1 draft:

>

> An analysis in terms of likelihood and magnitude of a product’s threats is required to be able to determine the product’s risks.

> NOTE 1 This document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks.

> NOTE 3 A quantitative estimation of the cybersecurity risks can be performed using scoring systems that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to certain values.

# Annex D (informative): Risk evaluation guidance

## D.1 Mapping of risks to requirements