Update bookmarks for internal links

# Modal verbs terminology

In the present document "**shall**", "**shall not**", "**should**", "**should not**", "**may**", "**need not**", "**will**", "**will not**", "**can**" and "**cannot** are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

In the present document "**shall**", "**shall not**", "**should**", "**should not**", "**may**", "**need not**", "**will**", "**will not**", "**can**" and "**cannot** are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

"**must**" and "**must not**" are **NOT** allowed in ETSI deliverables except when used in direct citation.

[Clause 6](#assessment-criteria-for-compliance-with-technical-requirements) specifies the assessment criteria and compliance verification procedures with the requirements of clause 5.

[Annex A](#_annex.a) maps the technical requirements of the present document with the essential requirements of the CRA [\[i.1\]](#_ref_i.1) regulation.

[Annex A](#annex-a-informative-relationship-between-the-present-document-and-the-requirements-of-eu-regulation-eu-20242847---the-cyber-resilience-act) maps the technical requirements of the present document with the essential requirements of the CRA [\[i.1\]](#_ref_i.1) regulation.

[Annex B](#_annex.b) informs about the methodology used to assess the security risks of the products in their context.

[Annex B](#annex-b-informative-security-analysis) informs about the methodology used to assess the security risks of the products in their context.

[Annex K](#_annex.k) supports the definition of the cryptographic requirements and assessment criteria used by the present document.

[Annex K](#annex-k-normative-generic-requirements-and-assessment-criteria-for-the-use-of-state-of-the-art-cryptography) supports the definition of the cryptographic requirements and assessment criteria used by the present document.

[Annex R](#_annex.r) provides supplementary requirements and assessment provisions where a product relies on remote data processing solutions (RDPS) for the provision or support of one or more product functions.

[Annex R](#annex-r-normative-remote-data-processing-solutions) provides supplementary requirements and assessment provisions where a product relies on remote data processing solutions (RDPS) for the provision or support of one or more product functions.

[//]: # (TODO delete this line or write Annex G)

Further information on guidance for the application of the present document is provided in [annex G](#_annex.g).

Further information on guidance for the application of the present document is provided in [annex G](#annex-g-informative-guidelines-on-the-implementation-of-the-present-document).

# 1 Scope

The present document specifies technical requirements and corresponding assessment criteria for Virtual Private Networks related to cybersecurity. The products with digital elements in scope, thereafter “VPNs”:

* are specified within the “technical description” of the “category of product” number “5” by the Commission Implementing Regulation (EU) 2025/2392 [\[i.2\]](#_ref_i.2) as: “Products with digital elements that establish an encrypted logical tunnel that is constructed from the system resources of a physical or virtual network.”

* are only covered within the product context described in [clause 4](#_clause.4) and the text of this clause.

* are only covered within the product context described in [clause 4](#product-context) and the text of this clause.

In particular, the present document specifies technical characteristics and methods of assessment for:

3. Software that operates as a VPN server

4. Remote data processing, specifically VPN server software performing the logical server role, and associated software used for such VPN products

The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I Part I under the conditions identified in [annex A](#_annex.a).

The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I Part I under the conditions identified in [annex A](#annex-a-informative-relationship-between-the-present-document-and-the-requirements-of-eu-regulation-eu-20242847---the-cyber-resilience-act).

VPN hardware or appliances, and control mechanisms for mesh VPNs are excluded from the present document.

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

> NOTE 1: The term “cryptographic mechanism” is used 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 1: The term “cryptographic mechanism” is used 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 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.

### 4.1.1 Overview

The VPN product is a collection of software running on different devices, contextually referred to as nodes. **Each element may have a different set of functionality** and may be more or less trusted than other elements. How the functionality and trust are distributed vary according to the architecture (see clause 4.4) and use case (see clause 4.6) of the VPN. For example, a VPN intended to protect the end user devices from surveillance would prefer an architecture that did not trust any node not controlled by that user.

The VPN product is a collection of software running on different devices, contextually referred to as nodes. **Each element may have a different set of functionality** and may be more or less trusted than other elements. How the functionality and trust are distributed vary according to the architecture (see [clause 4.4](#distribution-of-security-functions)) and use case (see [clause 4.6](#use-cases)) of the VPN. For example, a VPN intended to protect the end user devices from surveillance would prefer an architecture that did not trust any node not controlled by that user.

### 4.1.2 Potential functions of a node

#### 4.2.4.1 Server & gateway responsibilities

While [clause 4.1](#41-product-functions) establishes that any node within a VPN network may dynamically fulfill various operational roles, the terms “VPN server” and “VPN gateway” are used to describe nodes primarily dedicated to aggregation, routing, and access control.

While [clause 4.1](#product-functions) establishes that any node within a VPN network may dynamically fulfill various operational roles, the terms “VPN server” and “VPN gateway” are used to describe nodes primarily dedicated to aggregation, routing, and access control.

A **VPN server** is responsible for maintaining secure tunnels between multiple VPN clients and the traffic destinations the clients are requesting. It typically enforces centralized authentication, authorization, and traffic filtering policies. In decentralized or mesh VPN architectures, a “server” is not necessarily a dedicated, centralized appliance; rather, it is a logical role that any authorized peer node can assume to route traffic or act as an exit node for other peers.

#### 4.2.4.2 Server & gateway remote data processing

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. These typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on customer infrastructure. Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, such reliance introduces a product-facing RDPS boundary between the local product side and the RDPS side. RDPS-side VPN servers and gateways are held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in Annex R.

When VPNs are reliant on servers, gateways, or “exit nodes” operated by the manufacturer, those operations make up an important part of the product architecture. These typically serve the same functions as any other server or gateway, but remain entirely under the control of the manufacturer instead of being deployed on customer infrastructure. Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, such reliance introduces a product-facing RDPS boundary between the local product side and the RDPS side. RDPS-side VPN servers and gateways are held to the same requirements as any other VPN server or gateway, in addition to the requirements laid out in annex R.

### 4.2.5 Management server

### 4.3.3 Software environment

VPNs can be expected to operate in a network environment alongside other Important products such as Identity and Access Management Systems, Network Interfaces, Routers, Firewalls, and SIEM systems. Manufacturers are expected to harden VPN attack surfaces against potential attack vectors from compromised PwDEs, but in particular those considered Important and Critical. See [clause 4.5](#45-users) for further information about the relationship between VPNs and related software.

VPNs can be expected to operate in a network environment alongside other Important products such as Identity and Access Management Systems, Network Interfaces, Routers, Firewalls, and SIEM systems. Manufacturers are expected to harden VPN attack surfaces against potential attack vectors from compromised PwDEs, but in particular those considered Important and Critical. See [clause 4.5](#users) for further information about the relationship between VPNs and related software.

A VPN requires an existing physical or virtual network whose resources it can use. The underlying network provides the functions necessary to connect to at least one node of the VPN.

## 4.5 Users

To ensure that the cybersecurity requirements address the specific threats faced by different market segments, the users of VPN products are categorized into groups based on their operational needs, level of cybersecurity expertise, and risk profiles. This categorization considers both direct end-users and integrators, and prioritizes the privacy, safety, and accessibility of the product for all individuals. These user groups directly correspond to the Use Cases (UC) detailed in [clause 4.6](#46-use-cases):

To ensure that the cybersecurity requirements address the specific threats faced by different market segments, the users of VPN products are categorized into groups based on their operational needs, level of cybersecurity expertise, and risk profiles. This categorization considers both direct end-users and integrators, and prioritizes the privacy, safety, and accessibility of the product for all individuals. These user groups directly correspond to the Use Cases (UC) detailed in [clause 4.6](#use-cases):

- Everyday Consumers and Vulnerable Groups (Refers to UC-1, UC-2): This group represents the general public, specifically including vulnerable populations such as children and the elderly, as well as individuals with limited cybersecurity knowledge. Their primary needs include securing personal traffic on untrusted networks and obfuscating online activity to avoid tracking. This segment requires highly accessible, secure-by-default configurations that accommodate users with disabilities who may rely on assistive technology to operate the product securely.

- High-Risk Privacy Seekers (Refers to UC-3): This group represents individuals at a severe risk of targeted surveillance (e.g., privacy-conscious users operating in hostile environments). Their primary need is advanced privacy preservation to protect their personal safety, health, and human rights against capable adversaries and unsanctioned state actors.

::include{file=clauses/6.Assessment-Criteria.md}

# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act <span id="_annex.a"></span>

# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act

The present document has been prepared in response to the Commission's standardisation request C(2025)618 [\[i.3\]](#_ref_i.3) to provide, in additions to its other uses, one voluntary means of conforming to the essential requirements of Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) known as the Cyber Resilience Act (CRA).

Once the present document is cited in the Official Journal of the European Union under Regulation (EU) 2024/2847 [\[i.2\]](#_ref_i.2), conformance with the normative clauses of the present document given in the tables in [Annex A](#_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.

Once the present document is cited in the Official Journal of the European Union under Regulation (EU) 2024/2847 [\[i.2\]](#_ref_i.2), conformance with the normative clauses of the present document given in the tables in [annex A](#annex-a-informative-relationship-between-the-present-document-and-the-requirements-of-eu-regulation-eu-20242847---the-cyber-resilience-act`) 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.

<span id="tab_ACRA"></span>

Other Union legislation may be applicable to the product(s) falling within the scope of the present document.

# Annex B (informative): Security analysis <span id="_annex.b"></span>

# Annex B (informative): Security analysis

## B.0 Overview

This annex applies state-of-the-art methodology to identify threats and identify & evaluate risks based on product use cases.

The security analysis in this Annex represents a risk assessment done by the standardisers solely for the purpose of informing the applicability of technical requirements.

The security analysis in this annex represents a risk assessment done by the standardisers solely for the purpose of informing the applicability of technical requirements.

A list of product assets are used to identify potential threats to the product. The assumptions are used to define the scope of potential threats that are addressed by this security analysis.

The overall risk related to each use case should be considered as a result of combining risk factors affecting both likelihood and impact of an incident.

See annex [B.4.2](#b42-security-analysis-methodology) for the definition of risk factor levels.

See [clause B.4.2](#b.4.2-security-analysis-methodology) for the definition of risk factor levels.

### B.2.2 RF-CFG: End-point configuration

| USED   | AUTH, REQ-CON-15 (MI-CDST), SCDL, REQ-DRT-04 (MI-SDRF)                                      |

| CPER   | AUTH, DMIN, CRYPT, AUTH, ROUT, DNSL, REQ-CON-15 (MI-CDST), SCDL, REQ-DRT-04 (MI-SDRF), LOGG |

<span id="_annex.d"></span>

# Annex D: Accounting of requirements for each use case

[//]: # (TODO this has been temporarily abandoned until the editor can be confident that applicability is stable, at which time it will be updated or removed depending on document needs.)

⁴ REQ-SU-06 (MI-SUAP) or REQ-SU-09 (MI-SUAO) apply  

⁵ REQ-EMM-02 (MI-NUTI-1) or (REQ-EMM-03 (MI-TRAF-2) and REQ-EMM-04 (MI-TRAF-3) and REQ-EMM-05 (MI-TRAF-4)) apply  

# Annex G (informative): Guidelines on the implementation of the present document <span id="_annex.g"></span>

# Annex G (informative): Guidelines on the implementation of the present document

_This annex is optional and may be referred to from the Introduction of the document to provide more information on how to implement the standard._

# Annex K (normative): Generic requirements and assessment criteria for the use of state-of-the-art cryptography <span id="_annex.k"></span>

# Annex K (normative): Generic requirements and assessment criteria for the use of state-of-the-art cryptography

::include{file=clauses/K.Cryptography.md}

# Annex R (normative): Remote Data Processing Solutions <span id="_annex.r"></span>

# Annex R (normative): Remote Data Processing Solutions

::include{file=clauses/R.RDPS.md}