Editorial: ms word-friendly internal links

[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.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.

**Table A.1: Correspondence between the European Standard and Annex I Part I of Regulation (EU) 2024/2847**<span id="table_A.1"></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

(previously # Annex C (informative): Cybersecurity threat landscape, risk identification and assessment methodology)

<mark>Editor's Note: Even if informative, this Annex is mandatory in CRA Vertical Harmonised Standards, as it implements the risk-based approach prescribed in the CRA Regulation.</mark>

_The standard may implement an existing methodology, referencing the standards where it is defined. Alternatively, the following structure has been proposed as part of the HAS comments received, that may be adapted as relevant for each vertical:_

_B.1 Assets_

_B.2 Risk factors_

_B.3 Assumptions_

_B.4 Threats (including connection to risk factors)_

_B.5 Mapping of risk factors to use cases_

_Use technical language and focus what is relevant from a product perspective_

## B.0 Introduction

## 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.

## B.1 Assets

(previously ## C.1)

### B.1.0 Overview

The purpose of cybersecurity is to protect the product assets, which include product data, product functions, digital assets, human-related assets, and hardware. The compromise of each type of asset will have a different impact on the cybersecurity and the functionality of the product. Each asset has a corresponding value to the cybersecurity of the asset.

### B.1.1 Data assets

(previously ### C.1.1)

<span id="tab_BDA"></span>

Table { seq tab }: VPN product data assets

| Asset                                 | Compromise impacts                    | Value  |

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

### B.1.2 Product functions

(previously ### C.1.2)

What follows is a basic overview of VPN functions. See [clause 4.2](#product-architecture) for a detailed overview of the functions of a VPN product.

<span id="tab_BPF"></span>

A basic overview of VPN functions follows. See [clause 4.2](#42-product-architecture) for a detailed overview of the essential functions of a VPN product.

Table { seq tab }: VPN product functions

| Asset                                           | Compromise impacts            | Value  |

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

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 [C.4.2](#c42-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.

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

Rationale: The complexity of the end-point configuration can directly affect the likelihood of threats

* **[CFG-0]** End-point requires no configuration

* **[CFG-1]** End-point requires simple configuration, such as selecting an established VPN protocol or choosing a region to connect to

* **[CFG-1]** End-point requires simple configuration, such as selecting an established VPN protocol or selecting a region to which to connect

* **[CFG-2]** End-point requires configuration by a skilled administrator

### C.2.3 RF-AUT: Account management and authentication of endpoints

* **[COM-1]** Usage requires a few additional features related to tunnelling encrypted traffic

* **[COM-2]** Usage requires many additional features

Guidance: At present, the complexity of the implementation and the exposed interfaces are accounted for in a single risk factor. This is sufficient for the security analysis in the present document but may need to separated into two risk factors for future versions.

Guidance: At present, the complexity of the implementation and the exposed interfaces are accounted for in a single risk factor. This is sufficienty for the security analysis in the present document but may need to separated into two risk factors for future versions.

### C.2.10 RF-CON: Connectivity offered

* Medium to Low: REQ-DM-02 (MI-NPER-1)

* High to Low: REQ-DM-02 (MI-NPER-1), REQ-DM-03 (MI-NPER-2), REQ-DM-04 (MI-NPER-3), REQ-DM-05 (MI-NPER-4), LOGG-4, LOGG-5

## C.5 Mapping of use cases to risk factors

## B.5 Mapping of use cases to risk factors

<span id="tab_MAP"></span>

**Table C.5-1: Mapping of use cases to risk factors**

Table { seq tab }: Mapping of use cases to risk factors

| Use case | Description                 | CFG | AUT | FUN | ADM | RDP | DNC | COM | CON | PER |

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

| UC-6     | Enterprise client software  | 1   | 0   | 2   | 1   | 0   | 0   | 2   | 0   | 1   |

| UC-7     | Mesh network                | 2   | 2   | 1   | 1   | 1   | 2   | 2   | 0   | 1   |

## C.7 Risks not treated by the requirements

## B.6 Risks not treated by the requirements

(Previously ## D.4, TODO recalculate table)

[//]: # (TODO recalculate table)

For each risk untreated by the product itself, a corresponding mitigation has been created to explicitly permit the risk to be transferred to the user or operational environment. These are:

  * MI-DOST

  * REQ-AAC-07 (MI-AUTH-6)

## C.X Mapping of risks to requirements

## B.7 Mapping of risks to requirements

**Table 1: Mapping of risks to requirements**<

<span id="tab_MRR"></span>

_Editor's note: this table must be updated before the draft can be considered Final_

Table { seq tab }: Mapping of risks to requirements

[//]: # (TODO this table must be updated before the draft can be considered Final)

| Threat | Requirements                                                                                |

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

| 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

<mark>Editor's note: 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.</mark>

[//]: # (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.)

## D.1 _UC-1_ Individual consumer

⁴ 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}