Whitespace cleanup, align with skeleton, remove clause 5

<div align="center">

<div style="text-align: center;">

![~~ETSI Standard header image~~](media/etsi-coverpage-logo.png)

</div>

> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the " [Principles for Drafting ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf)" document. Otherwise you may contact us at [edithelp@etsi.org](mailto:edithelp@etsi.org).

> Should you need a step-by-step guide for drafting an ETSI deliverable, please consult the "[Principles for Drafting ETSI Deliverables]" document. Otherwise you may contact us at <edithelp@etsi.org>.

<br />

<br />

<br />

<br />

<div align="center">

<div style="text-align: center;">

Reference<br />

&lt;Workitem><br />

Keywords<br />

<br />

<div align="center">

<div style="text-align: center;">

**_Important notice_**

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format on [ETSI deliver](ETSI deliver) repository.

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format on [ETSI deliver] repository.

Users should be aware that the present document may be revised or have its status changed, this information is available in the [Milestones listing](Milestones listing).

Users should be aware that the present document may be revised or have its status changed, this information is available in the [Milestones listing].

If you find errors in the present document, please send your comments to<br />the relevant service listed under [Committee Support Staff](Committee Support Staff).

If you find errors in the present document, please send your comments to  

the relevant service listed under [Committee Support Staff].

If you find a security vulnerability in the present document, please report it through our

[Coordinated Vulnerability Disclosure (CVD)](Coordinated Vulnerability Disclosure (CVD)) program.

[Coordinated Vulnerability Disclosure (CVD)][CVD] program.

<br />

All rights reserved.<br />

[Principles for Drafting ETSI Deliverables]: https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/Principles_for_drafting_ETSI_deliverables.pdf

[ETSI deliver]: http://www.etsi.org/deliver

[Milestones listing]: https://portal.etsi.org/Services/editHelp/Standards-development/Tracking-a-draft/Status-codes

[Committee Support Staff]: https://portal.etsi.org/People/Commitee-Support-Staff

[CVD]: https://www.etsi.org/standards/coordinated-vulnerability-disclosure

</div>

# Contents

# Intellectual Property Rights

## Essential patents

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database](https://ipr.etsi.org/).

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database].

Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

[ETSI IPR online database]: https://ipr.etsi.org/

## Trademarks

**DECT™** , **PLUGTESTS™** , **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™** , **LTE™** and **5G ™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM** ® and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT

The Technical Body should advise the ETSI Secretariat if the above default national transposition dates are inappropriate for the particular standard.

# 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] (Verbal forms for the expression of provisions).

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

[ETSI Drafting Rules]: https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules

# Executive summary

# Introduction

This standard does not apply to products that contain [vertical] or are part of [vertical] if the core purpose of the product is not that of an [vertical]. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with [vertical].

# 1 Scope

# 1.1 General

## 1.1 General

The present document describes how to demonstrate compliance with requirements in the EU Regulation 2024/2847 under the conditions identified in Annex <L> of the following types of VPN:

1)  Software that offers as a VPN client for a commercial VPN service

2) All remote data processing without which the product could not perform ons of its core functions 

# 1.2 Products in scope

## 1.2 Products in scope

> Detailed list of things that are in scope, to help manufacturers identify in-scope products. Make the scope as narrow as possible while still covering all products in the vertical. Use the latest draft of the technical descriptions to help. Technical experts are considered to be the authority for interpreting the meaning and definition of technical terms, so use your best technical judgement.

- Products which supply a VPN client to an end user and provide servers through which to route user outbound network traffic to a public network

- VPN products intended to increase privacy around network traffic

# 1.3 Products not in scope

## 1.3 Products not in scope

> Detailed list of things whose scope might be confusing, including parts of a system which are often included when the terms in the "in scope" section are used in general conversation. Reference the "Product Context" section again to remind the reader what operational environments are in scope.

## 2.1 Normative references

> **In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided** . See clauses 2.10.1 and 8.4 of the [EDRs](EDRs) and the communiqué on "[References in ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf)".

> **In Harmonised Standards these references shall be specific** (identified by date of publication and/or edition number or version number) **publicly available and in English, except in exceptional circumstances making sure that impacts have been evaluated and explanations have been given on how any negative implications should be avoided** . See clauses 2.10.1 and 8.4 of the [EDRs] and the communiqué on "[References in ETSI Deliverables][References]".

>

> Guidance for selecting normative references in harmonised standards is given in clause 2.8.3 of the Vademecum on European standardisation. Please **systematically consult with your Technical Officer** for the latest guidance on normative references other than to ENs, ISO/IEC standards, notably to prevent the risk of non-acceptance.

>

>

> References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

>

> Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox](https://docbox.etsi.org/Reference/).

> Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox].

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

- <a name="_ref_1">[4]</a>    ETSI ## (##): TK shared vocabulary document from WG9

- <a name="_ref_1">[5-N]</a>  TK TODO related verticals, horizontals

[EDRs]: https://portal.etsi.org/Services/editHelp!/Howtostart/ETSIDraftingRules.aspx

[ETSI docbox]: https://docbox.etsi.org/Reference/

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

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

> - or as defined in [References in ETSI Deliverables](https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf)

> - or as defined in [References in ETSI Deliverables][References]

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long-term validity.

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.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.3">[i.3]</a>    CLC EN 62443-5-XX (): “Security Profile for network management systems”

* <a name="_ref_i.4">[i.4]</a>    Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity Act)

[References]: https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf

# 3 Definition of terms, symbols and abbreviations

## C.3 Assumptions

> List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases.

- Not being attacked by a state actor

- Not using sophisticated or expensive hardware snooping techniques

- No secret hardware backdoors

**It should be evaluated - on the basis of the legal requirements supported and other information given in a harmonised standard - how detailed correspondence can be indicated between the normative elements of the harmonised standard and the legal requirements aimed to be covered. However, where this correspondence is expressed in too general terms, it could lead to a situation where the Commission cannot assess whether the Harmonised Standard satisfies the requirements, which it aims to cover, and subsequently publication of its references in the OJEU according to Article 10(6) of the Regulation is significantly delayed or is not possible at all.**

> **EXAMPLE for a table:**

**Table A.1: Relationship between the present document and<br />the requirements of EU Regulation 2024/2847**<a name="table_A.1"></a>

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

|Harmonised Standard ETSI EN 304 63D                                                                     |

+:==+:==========+:=========================+:================================+:================+:========+

|Requirement                                                                 |Requirement Conditionality |

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

|No |Description|Requirements of Regulation|Clause(s) of the present document|U/C              |Condition|

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

Harmonised Standard ETSI EN 304 63D

| Requirement |                 |                                |                                       | Requirement Conditionality |               |

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

| **No**      | **Description** | **Requirements of Regulation** | **Clause(s) of the present document** | **Use case**               | **Condition** |

| 1           |                 |                                |                                       |                            |               |

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

| 2           |                 |                                |                                       |                            |               |

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

| 3           |                 |                                |                                       |                            |               |

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

| ...         |                 |                                |                                       |                            |               |

+---+-----------+--------------------------+---------------------------------+-----------------+---------+

**Key to columns:**

The annex shall have at least the following two warnings.

A warning stating that presumption of conformity is effective only as long as the reference is maintained in the OJEU by the Commission. The following URL-address [https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en](https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en) to consult the latest list of Harmonised Standards published in the OJEU should be provided.

A warning stating that presumption of conformity is effective only as long as the reference is maintained in the OJEU by the Commission. The following URL-address <https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards_en> to consult the latest list of Harmonised Standards published in the OJEU should be provided.

Presumption of conformity stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal of the European Union. Users of the present document should consult frequently the latest list published in the Official Journal of the European Union.

# 5 Requirements specifications

## 5.1 General

## 5.2 Technical security requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

> Example technical security requirements can be found in related standards, such as:

>

> - Protection profiles for similar categories of product

> - [EN-18031-2 (Radio Equipment Directive)](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09/CEN-CLC-JTC%2013-WG%209_N433_EN%2018031%20series.zip)

> - Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)

> - Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

**TODO: specific known attack vectors to apply to appropriate requirements**

- Credential harvesting

- Traffic hijacking

- Circumventing encryption

- Unauthorized reads of config data

- Remote code execution

- DNS Leaks to local network

- Allowing untrusted traffic

- Traffic validity failure

- authentication failure

- observation or disclosure of the user's online activity by an unauthorized and/or malicious party, including delayed disclosure

- config error causing misrouting of traffic

- utter betrayal

- unauthorized use of exit node (\*\* by service provider)

- unauthorised collection of PII by client

- unauthorised filtering or tampering of traffic (mitm)

## 5.3 [KEV] Known exploitable vulnerabilities

## 5.4 [CONFIG] Configuration

### 5.4.1 [CONFIG-1] Encryption by default

#### 5.4.1.1 Requirement

If a VPN product is capable of encrypting traffic between points, it **shall** be released to the market with encryption enabled.

#### 5.4.1.2 Rationale

VPNs carry with them an expectation of secure communication over the wire.

#### 5.4.1.3 Guidance

#### 5.4.1.4 Assessment criteria

### 5.4.2 [CONFIG-2] User intent

#### 5.4.2.1 Requirement

User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.

### 5.4.3 [CONFIG-3] Validation

#### 5.4.3.1 Requirement

User-manageable VPN settings shall be configurable in a manner that introducing unexpected punctuation or other formatting errors cannot result in a failure of encryption.

## 5.5 [ACM] Authentication and access control mechanisms

## 5.6 [TKTK] Integrity protection

## 5.7 [TKTK] Confidentiality protection

## 5.8 [TKTK] Data minimization

Personal VPNs: don't log traffic activity

Any logged traffic activity is subject to replay exposure

## 5.9 [TKTK] Availability protection

## 5.10 [TKTK] Impact minimization

Go into enterprise security here, specifically describe potential mitigations that may be complimentary to VPN

## 5.11 [TKTK] Limit attack surface

## 5.12 [TKTK] Logging and monitoring mechanisms

Basic level: DON'T

Middle & Critical level: LOG CONFIG CHANGES

## 5.13 [TKTK] Deletion mechanisms

## 5.12 [TKTK] Other product's technical requirements specifications

# 5 Requirements specifications

## 5.1 General

## 5.2 Technical security requirements specifications

> List technical security requirements for the product. Each requirement should be objectively verifiable on an instance of a product. Each should include an implementable method of verifying the requirement is met. Each should include a way to determine if the requirement is applicable to the product. Ideally each will include at least one concrete example of an implementation that satisfies the requirement and a test that verifies it. If the requirement allows the manufacturer to specify their own solution to the technical requirement, the requirement should include a specific way to measure the effectiveness of the risk mitigation and set a minimum level.

> Example technical security requirements can be found in related standards, such as:

>

> - Protection profiles for similar categories of product

> - [EN-18031-2 (Radio Equipment Directive)](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09/CEN-CLC-JTC%2013-WG%209_N433_EN%2018031%20series.zip)

> - Other vertical standards drafts in [ETSI GitLab](https://forge.etsi.org/rep/cyber/stan4cr2)

> - Other vertical standards drafts as [contributions to verticals meetings on the ETSI Portal](https://portal.etsi.org/Meetings.aspx#/)

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

TODO: specific known attack vectors to apply to appropriate requirements

- Credential harvesting

- Traffic hijacking

- Circumventing encryption

- Unauthorized reads of config data

- Remote code execution

- DNS Leaks to local network

- Allowing untrusted traffic

- Traffic validity failure

- authentication failure

- observation or disclosure of the user's online activity by an unauthorized and/or malicious party, including delayed disclosure

- config error causing misrouting of traffic

- utter betrayal

- unauthorized use of exit node (\*\* by service provider)

- unauthorised collection of PII by client

- unauthorised filtering or tampering of traffic (mitm)

## 5.3 [KEV] Known exploitable vulnerabilities

## 5.4 [CONFIG] Configuration

### 5.4.1 [CONFIG-1] Encryption by default

#### 5.4.1.1 Requirement

If a VPN product is capable of encrypting traffic between points, it **shall** be released to the market with encryption enabled.

#### 5.4.1.2 Rationale

VPNs carry with them an expectation of secure communication over the wire.

#### 5.4.1.3 Guidance

#### 5.4.1.4 Assessment criteria

### 5.4.2 [CONFIG-2] User intent

#### 5.4.2.1 Requirement

User interfaces, especially in regard to settings, shall be designed in a manner that prevents unintentional disabling of default security features.

### 5.4.3 [CONFIG-3] Validation

#### 5.4.3.1 Requirement

User-manageable VPN settings shall be configurable in a manner that introducing unexpected punctuation or other formatting errors cannot result in a failure of encryption.

## 5.5 [ACM] Authentication and access control mechanisms

## 5.6 [TKTK] Integrity protection

## 5.7 [TKTK] Confidentiality protection

## 5.8 [TKTK] Data minimization

Personal VPNs: don't log traffic activity

Any logged traffic activity is subject to replay exposure

## 5.9 [TKTK] Availability protection

## 5.10 [TKTK] Impact minimization

Go into enterprise security here, specifically describe potential mitigations that may be complimentary to VPN

## 5.11 [TKTK] Limit attack surface

## 5.12 [TKTK] Logging and monitoring mechanisms

Basic level: DON'T

Middle & Critical level: LOG CONFIG CHANGES

## 5.13 [TKTK] Deletion mechanisms

## 5.12 [TKTK] Other product's technical requirements specifications