Editorial pass

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

- Indirect Users: Where a VPN product (such as a VPN-enabled router) is deployed in a public space, the product design must also consider the cybersecurity needs, privacy, and safety of indirect users who are impacted by or whose traffic passes through the device

- Indirect Users: Where a VPN product (such as a VPN-enabled router) is deployed in a public space, the product design also is expected to consider the cybersecurity needs, privacy, and safety of indirect users who are impacted by or whose traffic passes through the device

## 4.6 Use Cases

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

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

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.

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.2.1.3 Compilation mitigation mechanisms (MI-SCFS)

In addition to memory safety, compiled software is a potential target based on platform and language. Products hardened against these known attack vectors reduce risk to end users.

#### 5.5.12.3 Guidance

The product needs a method of knowing what specific updates are valid for installation. Because of the requirement REQ-SU-13 (MI-SURP) (rollback protection), the product must have a method of knowing also which previously-valid updates are no longer valid. A simple way of doing this is by providing the device with a metadata file listing all updates that are valid along with each update's hash, size, and name. The device downloads this metadata file upon each update check, verifies that it is signed by a valid signing key, and performs other necessary checks (such as checking expiry or replacement).

The product needs a method of knowing what specific updates are valid for installation. Because of the requirement REQ-SU-13 (MI-SURP) (rollback protection), the product also needs a method of knowing also which previously-valid updates are no longer valid. A simple way of doing this is by providing the device with a metadata file listing all updates that are valid along with each update's hash, size, and name. The device downloads this metadata file upon each update check, verifies that it is signed by a valid signing key, and performs other necessary checks (such as checking expiry or replacement).

### 5.5.13 REQ-SU-13 (MI-SURP) Invalidated update is rejected

When enforcing pre-shared secrets, certificates, or fingerprints, some options may be: TLS certificates already installed on the platform, configuration files containing secrets, credentials provided as part of the product or distributed remotely via an authenticated connection, fingerprints of keys that are distributed on a website or in accompanying documentation, along with instructions to the user on how to verify.

### 5.6.3 REQ-AAC-03 (MI-AUTH-2) Transmitted credentials must be encrypted

### 5.6.3 REQ-AAC-03 (MI-AUTH-2) Encryption of transmitted credentials

#### 5.6.3.1 Requirement

### 5.7.12 REQ-CON-12 (MI-IPV6-1) Block IPv6 if Unsupported (MI-IPV6-1)

#### 5.7.12.11 Requirement

#### 5.7.12.1 Requirement

If the VPN does not support IPv6, the VPN client shall block all IPv6 traffic to prevent it from leaking outside the VPN tunnel.

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

* UC-1: required

* UC-2: required

#### 5.10.4.1 Requirement

1. **REQ-AP-04 (MI-DOST-1)-1** The product shall be accompanied by documentation informing the user that denial-of-service protection must be provided by the environment, and

1. **REQ-AP-04 (MI-DOST-1)-1** The product shall be accompanied by documentation informing the user that denial-of-service protection is expected to be provided by the environment, and

2. **REQ-AP-04 (MI-DOST-1)-2** documentation shall be in a form appropriate for a typical user for the intended purpose of the product.

#### 5.10.4.2 Applicability

#### 5.14.3.3 Guidance

One type of event for which log messages must take care to not accidentally include a secret is failed password authentication attempts. Since users often type a password into the username field, including the username field in the log message may result in including a secret in the log message.

Logging output is expected to take care to not accidentally include a secret as a result of failed password authentication attempts. Since users often type a password into the username field, including the username field in the log message may result in including a secret in the log message.

### 5.14.4 REQ-LOG-04 (MI-LOGG-3) No-Logs Policy and Traffic Anonymization

* Packet capture

* Log of user actions, if any

### 6.6.3 REQ-AAC-03 (MI-AUTH-2) Transmitted credentials must be encrypted

### 6.6.3 REQ-AAC-03 (MI-AUTH-2) Encryption of transmitted credentials

#### 6.6.3.1 Objective