Deletions: editorial comments and unused media.

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

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

# 1 Scope

<mark>Editor's Note: This is the normative clause of the standard, defining the technical requirements to implement the Essential Cybersecurity Requirements of the CRA regulation.</mark>

<mark>Editor's Note: Requirements should be written with "shall" statements.</mark>

<mark>Editor's Note: Requirements should be on the product and should not establish a process. Consequently, it is not appropriate to state "the manufacturer shall xx". Lifecycle requirements are equally unacceptable.</mark>

<mark>Editor's Note: Requirements should only concern the essential requirements of the CRA (Annex I Part I) and no other legal obligations established in the CRA. Most notably, the standard should not mandate the manufacturer to perform a risk assessment or draft instructions and information to users. Documentation, however, can be used as part of the conformity assessment (the following Clause).</mark>

<mark>Editor's Note: The requirements shall be indexed, to facilitate their referencing, preferably using a common indexing structure throughout all standards.</mark>

<mark>Editor's Note: Proposed structure for indexing the requirements in ETSI deliverables:

* REQ-PP-[TECHNICAL-FAMILY]-NNN REQ: Used to identify requirement in the text

* PP : Product short name added only if relevant when the product category may be divided in sub categories

* TECHNICAL FAMILY :Proposed abbreviations referring to the technical domain covered by the requirement

* NNN - Incremental and unique sequence of numbers and letters

</mark>

<mark>Editor's Note: Requirements should be unambiguous regarding the preferred implementation, ensuring that specific security qualities of the product are achieved, the presence of which can be consistently and deterministically tested. Accordingly, vague or contextual requirements such as use of "state-of-the-art techniques" or "authentication mechanism" are not sufficiently granular. Instead, all viable concrete options shall be listed with a clearly indicated prioritization and potentially a selection process.</mark>

<mark>Editor's Note: It is strongly recommended to follow the sequence of the CRA Annex I requirements when defining the subclauses in Clause 5. However, where this structure would result in unnecessary duplication/overlap, subclauses and requirements may be organized in a more suitable way, provided that clear traceability to the relevant CRA Annex I requirements is maintained. A notable example of such an exception would be essential requirement (2)(b) on a secure-by-default configuration, which includes all configuration and thus also extends to the areas covered by other essential requirements.</mark>

<mark>Editor's Note: Where technical requirements rely on normative references to other standards, ensure those references are narrowly scoped, mapping out relevant clauses individually for larger sections and explaining the purpose of that content.</mark>

<mark>Editor's Note: Requirements should express one clear technical intent. Please divide technical requirements as much as needed to ensure this is the case.</mark>

<mark>Editor's Note: The cross vertical approach on RDPS should be followed as part of the technical requirements.</mark>

<mark>Editor's Note: Where integration of components is required to fulfil security functions, technical requirements should explain how to securely integrate these at the immediate architectural boundary, including interactions via interfaces to components and their configuration.</mark>

<mark>Editor's Note: Documentation of risks is not considered a means of risk mitigation. Accordingly, technical requirements must not resort to documentation as a security control, but may rather only require it to support later conformity assessment.</mark>

<mark>Editor's Note: The purpose of this standard is to make security decisions for the manufacturer to the greatest extent possible. Therefore, it is not acceptable to ask manufacturers to research and decide on a suitable approach as part of a documentation requirement instead of making a concrete recommendation.</mark>

<mark>Editor's Note: Where technical requirements rely on cryptographic primitives, protocols, and techniques, the cross vertical approach on cryptography needs to be followed.</mark>

<mark>Editor's Note: While the standard should primarily cover vertical requirements, it should also cover horizontal aspects reflecting best practices for IT systems in general. This produces a self-contained document with comprehensive guarantees.</mark>

<mark>Editor's Note: For a general interpretation of the meaning of individual essential cybersecurity requirements, consider reading corresponding clauses of prEN 40000-1-4 once released.</mark>

## 5.1 Introduction and applicability of the requirements

The technical requirements of the present document apply under the product context described in [clause 4](#_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.

## 5.2 Appropriate level of cybersecurity

<mark>Editor's Note: Please refer to point 7.2 of the Commission CRA draft legal guidance for this essential requirement.</mark>

<mark>Editor's Note: It is not adequate to normatively reference prEN 40000-1-2 (PT1) to fulfil this requirement.</mark>

### 5.2.1 Overview

#### 5.2.1.1 CRA Relevance

## 5.3 No known exploitable vulnerabilities

Editor's Note: This is also a requirement on the product. Thus, a reference to prEN 40000-1-3 is not sufficient to fulfil it. Example of requirement: "The product shall be exempt from vulnerabilities present in xxx section of the EUVD".

### 5.3.1 Overview

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).

## 5.8 Integrity protection

<mark>Perhaps Galina can lend her expertise to provide narrowly scoped requirements around data integrity</mark>

### 5.8.1 Overview

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).

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

<mark>Editor's Note: The assessment clause should not contain "hidden" requirements. This means that all required specificities regarding the technical requirements should appear in clause 5. Clause 6 is only about verifying that the product complies with such technical requirements.</mark>

<mark>Editor's Note: The assessment clause should not mandate a "self-assessment" or "third party conformity assessment". The assessment clause should be without prejudice to specific conformity assessment procedures as detailed in Annex VIII of the CRA.</mark>

<mark>Editor's Note: Elements of the assessment clause should map one-to-one to elements of the technical requirements clause, ensuring there is a direct correspondence both ways. This means there shall be no summary assessment criteria.</mark>

## 6.1 Introduction to the assessment and compliance criteria

[//]: # (TODO: write something in the inroduction of Clause 6 that if a product supports IPv6, all tests must be completed both on IPv4 and IPv6)

For each cybersecurity requirements defined in [clause 5](#5-technical-requirements-for-the-products), the following clauses specify assessment criteria to determine if the technical requirement is met.

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

- **Assessment reference:** Refers to the identifier of the concerned technical requirement.

<mark>Editor's Note: Ideally, the reference is formatted also as a link to th corresponding technical requirement clause, allowing readers to jump to that section (and back).</mark>

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

- **Assessment preparation:** Describes the environment, setup, and preconditions required before executing the test with a view to guaranteeing consistent evaluation results. 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 analysers, static code analysers, cryptographic test suites).

<mark>Editor's Note: Precisely reference individual tools or include an unambiguous characterization by way of tool capabilities to ensure consistent tool application. For instance, "state-of-the-art vulnerability scanner" shall instead be replaced with "vulnerability scanner that covers all CVEs, supports credentialed and non-credentialed scans, ..."</mark>

  - 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 such that the same assessment verdict would be reached when repeating these steps now or at a later point in time. 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).

<mark>Editor's Note: Checking documentation for the presence or absence of certain security controls should be the last resort or only a supporting activity, with strong preference given to actual verification of security qualities of the product by testing the final product or its source code.</mark>

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

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

- **Assessment 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;

<mark>Editor's note: The assessment criteria shall be indexed, to facilitate their referencing.</mark>

_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 Appropriate level of cybersecurity

### 6.2.1 Overview

## K.0 General

### K.0.1 Introduction

Editor’s note: Clause K.0 provides general context, terms and application guidance for vertical standards. Guidance and editorial instructions in this clause shall be removed or adapted when Annex K is integrated into a vertical standard. Terms and definitions in clause K.0.2 shall be moved to the terms and definitions clause of the vertical standard or retained in Annex K, as appropriate.

### K.0.3 Application Guidance for vertical standards

Vertical standards should use the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1) as the primary reference for cryptographic mechanisms, as defined in clause K.1.1 item 1.

Where the ACM catalogue is not sufficient, or where a cryptographic mechanism is not explicitly listed in the ACM catalogue, including a specific profile, restriction or configuration of an ACM-listed mechanism, the ACM-extended route in clause K.1.1 item 2 can be used. Vertical standards can specify or reference ACM-extended cryptographic mechanisms in clause K.3.2. For mechanisms not listed in clause K.3.2, the criteria in clause K.1.1 item 2.b apply.

Where a cryptographic mechanism is not classified as state-of-the-art cryptography but is needed for interoperability, vertical standards can specify or reference the mechanism in clause K.4.2, subject to the selection criteria defined therein. This covers cases where an external specification, operational constraint or interoperability requirement requires the use of such a cryptographic mechanism, provided that its use is identified, limited to the intended interoperability purpose and, where applicable, mitigated at system level. Inclusion of a cryptographic mechanism in clause K.4.2 does not classify it as state-of-the-art cryptography.

Clause K.1.2 defines the assessment of the product’s cryptographic default configuration. It is intended to verify that the cryptographic mechanisms used in the product’s default configuration are ACM-listed, ACM-extended under clause K.1.1 item 2, or interoperability-based under clause K.1.1 item 3, and that they are used in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.

Clause K.2 defines the crypto-agility requirement, and clause K.2.2 defines the corresponding assessment of crypto-agility mechanisms. This assessment verifies whether the product provides means to address situations where the ACM catalogue, or the vertical standard, specifies a deprecation date, expiry date, migration condition or usage limitation for a cryptographic mechanism used in the product’s default configuration, and where this lifecycle information falls within the intended lifetime of the product.

Vertical standards should specify cryptographic mechanisms at the level appropriate for the product functions and, where relevant, use cases, by identifying any relevant characteristics, parameters, protocol profiles, cipher suites, configuration constraints, conditions or limitations.

Where different product functions or use cases require different cryptographic mechanisms, profiles, conditions or limitations, clauses K.3.2 and K.4.2 should identify the related product function, use case where relevant, conditions or limitations for each listed cryptographic mechanism, and, for clause K.4.2, the relevant external specification or external requirement.

For interoperability-based cryptographic mechanisms, clause K.4.2 should also clearly identify the interoperability justification and any conditions or limitations needed to ensure secure and constrained use. Where the organisation accountable for the relevant specification is not explicitly listed in clause K.1.1 item 2.b ii. or clause K.4.0 item b., rapporteurs are to document additional supporting evidence before including the cryptographic mechanism in clause K.3.2 or K.4.2, respectively. Such evidence may include public technical review, SDO review, expert review, security proof, formal analysis, rigorous technical argument or dedicated security analysis.

If the vertical standard does not specify ACM-extended cryptographic mechanisms, clause K.3 should state that no ACM-extended cryptographic mechanisms are specified. If the vertical standard does not specify interoperability-based cryptographic mechanisms, clause K.4 should state that no interoperability-based cryptographic mechanisms are specified.

For the purpose of completing clauses K.3.2 and K.4.2, the vertical standard does not need to reproduce the full content of a referenced cryptographic catalogue, external specification or external requirement. It may reference the relevant catalogue entry, clause, table, profile, requirement or other uniquely identifiable part of the referenced source, provided that the cryptographic mechanism, its applicable characteristics, parameters, conditions or limitations, and the related product function or interoperability need are sufficiently identifiable for assessment.

## K.1 Cryptography

### K.1.1 Requirement

## K.3 ACM-extended cryptographic mechanisms

### K.3.0 Guidance for rapporteurs

Editor’s note for rapporteurs: This clause provides guidance for identifying ACM-extended cryptographic mechanisms to be listed in clause K.3.2 when preparing a vertical standard. It is not intended to remain as normative content in the published vertical standard. This clause shall be removed before publication, after the ACM-extended cryptographic mechanisms, where any, have been identified in clause K.3.2.

When preparing the list of ACM-extended cryptographic mechanisms in clause K.3.2, the criteria in clause K.1.1 item 2.b guide the selection of candidate ACM-extended cryptographic mechanisms.

### K.3.1 Requirement

Where the product’s default configuration uses ACM-extended cryptographic mechanisms, these mechanisms shall comply with the ACM-extended criterion in [clause K.1.1](#k11-requirement) item 2\.