Link annexes, experiment with linking clauses, clean whitespace.

The present document provides the technical cybersecurity requirements for the products in scope, following a risk-based approach in support of the Cyber Resilience Act (CRA) [\[i.1\]](#_ref_i.1). The technical cybersecurity requirements are thereby proportionate to the intended purpose, reasonably foreseeable use, deployment context, and threat exposure of the products.

Clause 4 does not contain technical requirements; it describes the product context that is considered for the application of this standard. 

[clause 4](#4-product-context) does not contain technical requirements; it describes the product context that is considered for the application of this standard.

Clause 4 also defines Use Cases (UCs) that represent the main deployment scenarios reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for identifying relevant cybersecurity risks.

[clause 4](#4-product-context) also defines Use Cases (UCs) that represent the main deployment scenarios reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for identifying relevant cybersecurity risks.

Clause 5 specifies technical cybersecurity requirements for the product to mitigate the identified risks, including their applicability conditions.

[clause 5](#5-technical-requirements-for-the-products) specifies technical cybersecurity requirements for the product to mitigate the identified risks, including their applicability conditions.

Clause 6 specifies the assessment criteria and compliance verification procedures with the requirements of Clause 5.

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

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) maps the technical requirements of the present document with the essential requirements of the CRA [\[i.1\]](#_ref_i.1) regulation.

Annex B informs about the methodology used to assess the security risks of the products in their context. 

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

<mark>Editor’s Note: Where the functionality of the product relies on cryptography, then Annex K shall be included and instantiated in the CRA Vertical standard to provide presumption of conformity with regards to cryptographic mechanisms embarked in the product.</mark>

Annex K supports the definition of the cryptographic requirements and assessment criteria used by the present document.

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

<mark>Editor’s Note: The following annexes are optional (may or may not be included in the vertical):</mark>

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

Further information on guidance for the application of the present document is provided in Annex G.

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

# 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 and the text of this clause.

* are only covered within the product context described in [clause 4](#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](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).

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

(previously ### 4.3.3)

While Clause 4.1 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](#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.

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.

The physical environment a VPN product may be deployed in affects the applicable risks and enables potential risk transfers.

VPN products may be deployed in various different environments such as different physical devices as well as different physical networks.

There are various types of devices, but they all share that the firewall is managed by the underlying system and outside of the control of the VPN product.

* **Network devices**: VPN products are often deployed on network devices to tunnel traffic to remote endpoints. Such network devices (for example a router) are usually located on the edge between a private and public network and thus exposed to internal as well as external attack surfaces. A firewall is usually included by the underlying OS or hardware system for such network devices.

* **Internet of Things, Consumer Gadgets and Appliances**: VPN products could be deployed on IoT devices, consumer gadgets, TVs or other appliances where the product is bound to the security model of the device hardware and operating system. The device might lack proper hardware security modules, firewall support, or enforce a relaxed security model (for example requiring the product to run as root without proper isolation between applications and users). Such devices are usually placed in private networks.

* **Consumer Devices**: VPN products are often deployed on consumer devices such as tablets, computers, mobile devices or laptops of various operating systems. The product is bound to the security model of the hardware and operating system. While such devices usually support firewalls and proper user isolation, the actual security configuration of such systems depends on the security awareness of the operating administrating user and the configuration limitations of the underlying system. Consumer devices are located in private networks.

* **Managed Endpoints**: Managed endpoints are professionally managed instances which are usually located on a physical or virtual server in a data centre. While the firewall configuration is done by the administrating user, this user is assumed to have advanced security knowledge. Further, the server is usually located in an access restricted data centre which transfers physical risk (for example memory snapshotting or injections) to the data centre provider.

Devices might be located in insecure networks, which could include one or even a combination of the following networks:

* **Secure professionally managed environment**: In professionally managed environments usually utilize a securely managed firewall, isolated network and application environments, properly configured and hardened operating systems, as well as proper security event monitoring to detect intruders or malicious activities. Devices are usually located in an access restricted environment such as data centers or private homes.

* **Private network**: Private networks are usually an isolated network which is protected by the router's firewall configuration. Devices deployed inside the private network can freely communicate which imposes a risk if one or many of the devices in the private network is compromised. Network traffic in such environment could be intercepted and inspected on outbound network devices. Physical risks to devices located in a private network are unlikely since most of the devices are located in the private and access restricted environment of the user.

* **Public network**: Public networks usually lack proper security configuration and network traffic might be eavesdropped, tampered or intercepted. The network may contain hostile devices and malicious users since the environment is not access restricted.

(previously ### 4.4.2)

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 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](#45-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.

(previously ## 4.6)

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:

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):

- 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

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

- Small Organization Users (Refers to UC-4): This group represents users operating within smaller entities lacking dedicated, full-time network administration. Their primary need is establishing secure remote connections to necessary operational resources, heavily relying on manufacturer-managed services to prevent misconfigurations.

- Enterprise Integrators and Administrators (Refers to UC-5, UC-6, UC-7): This group represents professional users, integrators, and administrators with privileged rights and professional cybersecurity training. Their primary needs include securely connecting multiple endpoints to private corporate networks, managing complex VPN infrastructures, and conducting extensive traffic inspection for security purposes.

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

<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.2\]](#_ref_i.2) 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 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) 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: Relationship between the present document and<br />the requirements of Regulation (EU) 2024/2847 - the Cyber Resilience Act**<a name="table_A.1"></a>

**Table A.1: Relationship between the present document and<br />the requirements of Regulation (EU) 2024/2847 - the Cyber Resilience Act**

[//]: # (TODO update this table after reordering.)

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

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

# Annex B (informative): Security analysis

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

## B.0 Introduction

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

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

## B.1 Assets

(previously ### C.1.2)

A basic overview of VPN functions follows. See clause 4.2 for a detailed overview of the essential functions of a VPN product.

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.

* Edge: uses a public network to communicate with the restricted use network

* Gateway: provides link between public network and restricted

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

⁵ 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  

⁶ REQ-DRT-02 (MI-RSET) or REQ-DRT-03 (MI-INST) or REQ-DRT-06 (MI-DELE) apply

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

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

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

<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: Remote Data Processing Solutions (Normative)

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

# Annex R (normative): Remote Data Processing Solutions

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

# Annex S: Secure Updates (Normative)

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

# Annex S (normative): Secure Updates

::include{file=clauses/S.Secure-Update.md}

## 5.1 Introduction - Applicability of the requirements

The technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.

The technical requirements of the present document apply under the product context described in [clause 4](#4-product-context), which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.

Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product.

#### 5.2.1.2 Secure software design and development (MI-SSCA, MI-FZ95, MI-BTIN, MI-IMSL)

Use cases (as described in clause 4.7 and Annex B) determine which of these controls should be utilized to mitigate threats around secure software design and development. In particular, across all use cases only one—at most—of the following three is called for when applied to a single product: REQ-SSD-03 (MI-FZ95), REQ-SSD-04 (MI-BTIN), REQ-SSD-05 (MI-IMSL). See B.TK for more information.

Use cases (as described in [clause 4.6](#46-use-cases) and [annex B](#_annex.b)) determine which of these controls should be utilized to mitigate threats around secure software design and development. In particular, across all use cases only one—at most—of the following three is called for when applied to a single product: REQ-SSD-03 (MI-FZ95), REQ-SSD-04 (MI-BTIN), REQ-SSD-05 (MI-IMSL). See B.TK for more information.

#### 5.2.2.3 Compilation mitigation mechanisms (MI-SCFS)

#### 5.5.10.1 Requirement

1. **REQ-SU-10 (MI-SUCS)-1** Updates for the product shall be cryptographically signed as defined in Annex K, and

1. **REQ-SU-10 (MI-SUCS)-1** Updates for the product shall be cryptographically signed as defined in [annex K](#_annex.k), and

2. **REQ-SU-10 (MI-SUCS)-2** the product shall verify the signature before installation in order to mitigate the installation of tampered and/or modified updates.

#### 5.5.10.2 Applicability

#### 5.5.11.1 Requirement

The product shall reject an update that does not match the expected cryptographic hash as defined in Annex K.

The product shall reject an update that does not match the expected cryptographic hash as defined in [annex K](#_annex.k).

#### 5.5.11.2 Applicability

#### 5.7.14.1 Requirement

The product shall use cryptographic primitives and parameters as defined in Annex K.

The product shall use cryptographic primitives and parameters as defined in [annex K](#_annex.k).

> NOTE: VPN protocols such as IPSec, Wireguard, OpenVPN and IKEv2 are approved VPN protocols if state-of-the-art cryptography as defined in Annex K is used.

> NOTE: VPN protocols such as IPSec, Wireguard, OpenVPN and IKEv2 are approved VPN protocols if state-of-the-art cryptography as defined in [annex K](#_annex.k) is used.

#### 5.7.14.1 Applicability

#### 5.7.15.1 Requirement

The product shall protect the confidentiality of stored data, whether personal or other, from unauthorized access by encrypting relevant data at rest using state-of-the-art mechanisms as defined in Annex [K](K) and by using other appropriate technical access controls.

The product shall protect the confidentiality of stored data, whether personal or other, from unauthorized access by encrypting relevant data at rest using state-of-the-art mechanisms as defined in [annex K](#_annex.k) and by using other appropriate technical access controls.

To ensure testability, the product shall explicitly implement protection mechanisms for confidential data stored locally on the endpoint or on remote nodes.

Depending on the data type and operational environment, the product shall protect these elements using one or more of the following methods:

* State-of-the-art encryption as defined in Annex [K](K) at rest

* State-of-the-art encryption as defined in [annex K](#_annex.k) at rest

* Hardware-backed secrets storage (e.g., Trusted Platform Module (TPM), Secure Enclaves)

* Cryptographic salting and hashing (specifically for stored passwords/secrets)

* Strict environment and file-system permissions restricting read/write access exclusively to the VPN client software and authorized administrators or users.

#### 5.10.6.2 Applicability

This requirement applies to all products within the below use cases, _except_ products which rely on a single node or dedicated IP address.

* UC-1: not required

#### 5.12.2.2 Applicability

* UC-1: required

* UC-2: required

* UC-3: required