Structural: Add (blank) normative annexes

---

Title: Cybersecurity (CYBER); CRA; Cybersecurity requirements for Virtual Private Networks

Spec Number: 304 620

Version: v0.1.7

Date: 2026-04-13

Version: v0.1.8

Date: 2026-04-20

Release: 5

Work Item: DEN/CYBER-EUS-005

keywords: CRA #KEYWORDS#

# 6 Assessment criteria for compliance with technical requirements

_It has been agreed across vertical standards to define each assessment criteria following the common structure:_

- _Requirement reference_

- _Objective_

- _Preparation_

- _Activities_

- _Verdict_

- _Evidence_

_The assessment criteria clause shall be structured by requirement defined in clause 5._

## 6.1 Introduction to the assessment and compliance criteria

This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5, based on the UC and/or the Security Profile it may belong towards its placement in the EU market.

For each cybersecurity requirements defined in Clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.

Please ensure that there is an easy, clear and unambiguous mapping of the requirements in clause 5 to the relevant assessment criteria in clause 6.

The assessment criteria for each security requirements are described in a structured manner, as follows:

- **Assessment Objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

  It includes the reference index of the requirement(s) it aims to assess.

- **Assessment Preparation:** Describes the environment, setup, and preconditions required before executing the test. It includes the following elements as applicable:

  - Test environment: Describe the hardware, software, and network setup used for the assessment, including versions, topology, and any relevant dependencies.

  - Preconditions: Specify any configurations, credentials, or operational states that should be established before the test (e.g. product initialized, certificates loaded, user roles created).

  - Required tools: Identify the tools or software necessary to perform the assessment (e.g. vulnerability scanners, protocol fuzzers, traffic analyzers, static code analyzers, cryptographic test suites).

  - Required information/documentation for the assessment: Specify all information that is necessary to perform the assessment

  - Reference any vendor-provided setup guides, configuration instructions, or operational manuals, as well as any relevant standards or technical notes, that define how the product shall be configured or operated for the assessment.

- **Assessment Activities:** Provides execution steps to be performed. Assessment activities may include, as applicable:

  - Review information/documentation for the assessment to confirm that the described implementation matches the requirement (e.g. verify that the security architecture document specifies TLS 1.2 or higher for all external interfaces, or that the password policy aligns with the defined threshold).

  - Perform security functional tests to verify the completeness and correctness of the information/documentation for the assessment

  - Perform security functional or penetration tests to verify that implemented controls are correctly implemented e.g. to prevent unauthorized access or data modification (e.g. via attempting to log in with invalid credentials to test lockout enforcement or trying to modify protected configuration files without administrative privileges).

  - Analyse code or binaries to identify potential security weaknesses or misconfigurations (e.g. perform static analysis to detect hardcoded credentials or use dynamic analysis tools to identify buffer overflow or injection vulnerabilities).

  - Inspect configurations to ensure that required security parameters are correctly applied (e.g. check that weak cipher suites are disabled, two-factor authentication is enabled, and least-privilege access controls are configured in the system).

  - Observe runtime behaviour to confirm that protections such as encryption, authentication, and integrity verification operate as intended (e.g. monitor network traffic to ensure data in transit is encrypted or observe system logs to verify successful validation of digital signatures during startup).

- **Assignment of Verdict:** Defines the pass/fail criteria.

  - **Pass:** The assessment is considered passed if the product demonstrably fulfils the requirement and meets the defined security thresholds. Examples of such thresholds include:

    - Minimum cryptographic strength (e.g. AES-128 or higher);

    - Password policy limits (e.g. minimum of 12 characters);

    - Login protection mechanisms (e.g. account lockout after five consecutive failed attempts);

    - Resistance to a specified attack potential (e.g. equivalent to CSA High/AVA\_VAN.3 or higher).

  - **Fail:** The assessment is considered failed if the requirement is not fulfilled, or if the defined security thresholds are not achieved (e.g. insufficient key length, missing authentication enforcement, or inadequate resistance to the required attack potential).

- **Supporting Evidence** : Defines the artefacts and documentation  collected to demonstrate that the requirement has been assessed and fulfilled. The evidence shall be sufficient to enable independent verification of the assessment results and to demonstrate compliance with the relevant CRA essential requirements. The supporting evidence include, where applicable:

  - Test or assessment reports showing the steps performed and results obtained;

  - Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

  - Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

  - Relevant vendor or design documentation describing the applied security measures;

_It would be very useful to use a common structure for the assessment criteria definition clause 6. The following is a proposal - to be discussed among rapporteurs._

_The assessment criteria shall be indexed, to facilitate their referencing, preferably using a common indexing structure throughout all standards and enabling an easy mapping with the requirements of Clause 5._

_Proposed structure for indexing the assessment criteria:_

_ACC - PP - ESR - NNN_

_ACC: Used to identify assessment and compliance criteria in the text_

_PP : Product short name added only if relevant when the product category may be divided in sub categories_

_ESR :Proposed abbreviations referring to the different essential requirements of the regulation_

_NNNNN - Incremental and unique sequence of numbers and letters - could be the same as for the corresponding requirement (if one-to-one match), otherwise a mapping would be needed_

## 6.2 No known exploitable vulnerabilities

Proposed ESR code: KEV

## 6.3 Secure by design

Proposed ESR code SBD

## 6.4 Secure Updates

Proposed ESR code: SU

## 6.5 Authentication and Access Control

Proposed ESR code: AAC

## 6.6 Confidentiality

Proposed ESR code: CON

In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography assessment criteria.

## 6.7 Integrity

Proposed ESR code: INT

## 6.8 Data Minimisation

Proposed ESR code: DM

## 6.9 Availability Protection

Proposed ESR code: AP

## 6.10 Impact Minimisation

Proposed ESR code: IM

## 6.11 Minimisation of Attack Surfaces

Proposed ESR code: MAS

## 6.12 Exploitation Mitigation Mechanisms

Proposed ESR code: EMM

## 6.13 Logging and Monitoring

Proposed ESR code: LOG

## 6.14 Data Removal and Transparency

Proposed ESR code: DRT

## 6.15 Vulnerability Handling

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be met for the product

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

_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: Cryptography (Normative)

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

# Annex R: Remote Data Processing Solutions (Normative)

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

# Annex S: Secure Updates (Normative)

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

# History

The following table will automatically be filled in by the ETSI Secretariat.

_It has been agreed across vertical standards to define each assessment criteria following the common structure:_

- _Requirement reference_

- _Objective_

- _Preparation_

- _Activities_

- _Verdict_

- _Evidence_

_The assessment criteria clause shall be structured by requirement defined in clause 5._

## 6.1 Introduction to the assessment and compliance criteria

This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5, based on the UC and/or the Security Profile it may belong towards its placement in the EU market.

For each cybersecurity requirements defined in Clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.

Please ensure that there is an easy, clear and unambiguous mapping of the requirements in clause 5 to the relevant assessment criteria in clause 6.

The assessment criteria for each security requirements are described in a structured manner, as follows:

- **Assessment Objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

  It includes the reference index of the requirement(s) it aims to assess.

- **Assessment Preparation:** Describes the environment, setup, and preconditions required before executing the test. It includes the following elements as applicable:

  - Test environment: Describe the hardware, software, and network setup used for the assessment, including versions, topology, and any relevant dependencies.

  - Preconditions: Specify any configurations, credentials, or operational states that should be established before the test (e.g. product initialized, certificates loaded, user roles created).

  - Required tools: Identify the tools or software necessary to perform the assessment (e.g. vulnerability scanners, protocol fuzzers, traffic analyzers, static code analyzers, cryptographic test suites).

  - Required information/documentation for the assessment: Specify all information that is necessary to perform the assessment

  - Reference any vendor-provided setup guides, configuration instructions, or operational manuals, as well as any relevant standards or technical notes, that define how the product shall be configured or operated for the assessment.

- **Assessment Activities:** Provides execution steps to be performed. Assessment activities may include, as applicable:

  - Review information/documentation for the assessment to confirm that the described implementation matches the requirement (e.g. verify that the security architecture document specifies TLS 1.2 or higher for all external interfaces, or that the password policy aligns with the defined threshold).

  - Perform security functional tests to verify the completeness and correctness of the information/documentation for the assessment

  - Perform security functional or penetration tests to verify that implemented controls are correctly implemented e.g. to prevent unauthorized access or data modification (e.g. via attempting to log in with invalid credentials to test lockout enforcement or trying to modify protected configuration files without administrative privileges).

  - Analyse code or binaries to identify potential security weaknesses or misconfigurations (e.g. perform static analysis to detect hardcoded credentials or use dynamic analysis tools to identify buffer overflow or injection vulnerabilities).

  - Inspect configurations to ensure that required security parameters are correctly applied (e.g. check that weak cipher suites are disabled, two-factor authentication is enabled, and least-privilege access controls are configured in the system).

  - Observe runtime behaviour to confirm that protections such as encryption, authentication, and integrity verification operate as intended (e.g. monitor network traffic to ensure data in transit is encrypted or observe system logs to verify successful validation of digital signatures during startup).

- **Assignment of Verdict:** Defines the pass/fail criteria.

  - **Pass:** The assessment is considered passed if the product demonstrably fulfils the requirement and meets the defined security thresholds. Examples of such thresholds include:

    - Minimum cryptographic strength (e.g. AES-128 or higher);

    - Password policy limits (e.g. minimum of 12 characters);

    - Login protection mechanisms (e.g. account lockout after five consecutive failed attempts);

    - Resistance to a specified attack potential (e.g. equivalent to CSA High/AVA\_VAN.3 or higher).

  - **Fail:** The assessment is considered failed if the requirement is not fulfilled, or if the defined security thresholds are not achieved (e.g. insufficient key length, missing authentication enforcement, or inadequate resistance to the required attack potential).

- **Supporting Evidence** : Defines the artefacts and documentation  collected to demonstrate that the requirement has been assessed and fulfilled. The evidence shall be sufficient to enable independent verification of the assessment results and to demonstrate compliance with the relevant CRA essential requirements. The supporting evidence include, where applicable:

  - Test or assessment reports showing the steps performed and results obtained;

  - Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

  - Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

  - Relevant vendor or design documentation describing the applied security measures;

_It would be very useful to use a common structure for the assessment criteria definition clause 6. The following is a proposal - to be discussed among rapporteurs._

_The assessment criteria shall be indexed, to facilitate their referencing, preferably using a common indexing structure throughout all standards and enabling an easy mapping with the requirements of Clause 5._

_Proposed structure for indexing the assessment criteria:_

_ACC - PP - ESR - NNN_

_ACC: Used to identify assessment and compliance criteria in the text_

_PP : Product short name added only if relevant when the product category may be divided in sub categories_

_ESR :Proposed abbreviations referring to the different essential requirements of the regulation_

_NNNNN - Incremental and unique sequence of numbers and letters - could be the same as for the corresponding requirement (if one-to-one match), otherwise a mapping would be needed_

## 6.2 No known exploitable vulnerabilities

Proposed ESR code: KEV

## 6.3 Secure by design

Proposed ESR code SBD

## 6.4 Secure Updates

Proposed ESR code: SU

## 6.5 Authentication and Access Control

Proposed ESR code: AAC

## 6.6 Confidentiality

Proposed ESR code: CON

In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography assessment criteria.

## 6.7 Integrity

Proposed ESR code: INT

## 6.8 Data Minimisation

Proposed ESR code: DM

## 6.9 Availability Protection

Proposed ESR code: AP

## 6.10 Impact Minimisation

Proposed ESR code: IM

## 6.11 Minimisation of Attack Surfaces

Proposed ESR code: MAS

## 6.12 Exploitation Mitigation Mechanisms

Proposed ESR code: EMM

## 6.13 Logging and Monitoring

Proposed ESR code: LOG

## 6.14 Data Removal and Transparency

Proposed ESR code: DRT

## 6.15 Vulnerability Handling

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be met for the product