Removed overlapping content and implementation notes from Annex K

## K.1 Cryptography

### K.1.1 Requirement

The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:

1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1);

2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1) and meets at least one of the following conditions:

   - a) the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);

   - b) where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:

     - i) the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1); - ii) the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including *\[list of organisations\];* or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognised national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including *\[list of catalogues\]*;

     - iii) the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;

     - iv) the cryptographic properties of the cryptographic mechanism are known;

     - v) no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;

     - vi) the cryptographic mechanism is required for a specific set of product functions;

     - vii) *\[any additional criteria specified by the vertical standard, where applicable\].*

3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).

> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.

> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.

> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document. The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.

> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context. An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.

> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.

> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.

### K.1.2 Assessment of product cryptographic configuration

#### K.1.2.0 General

## K.3 ACM-extended cryptographic mechanisms

### K.3.0 Guidance for rapporteurs

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

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

|:-------------------------------------|:------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|:-----------------------------------------------------------------------------|:------------------------------------------------------------------------|:----------------------------------------------------------------|:---------------------------------------------------------------------------------------------------|

| \<mechanism name\>                   | \<Algorithm / Primitive / Scheme / Protocol / Protocol profile / Cipher suite / Mode / Construction / Parameter set / Other\> | \<key length, mode, profile, cipher suite, parameter set, version, etc.\> | \<product function, interface, protocol context, operational context, etc.\> | \<confidentiality, integrity, authentication, key establishment, etc.\> | \<publicly available and uniquely referenceable specification\> | \<constraints, permitted use, excluded use, configuration limitation, lifecycle limitation, etc.\> |

<mark>Editor’s note for rapporteurs: Where no ACM-extended cryptographic mechanisms are specified by the vertical standard, this clause is to state: “No ACM-extended cryptographic mechanisms are specified.” This editor’s note shall be removed before publication.</mark>

<mark>Editor’s note for rapporteurs: Table K.1 is an example template and can be adapted where needed for the relevant vertical standard.</mark>

### K.3.3 Assessment

Compliance with the ACM-extended criterion in clause K.1.1 item 2 is assessed in clause K.1.2.2.

## K.4 Interoperability-based cryptographic mechanisms

### K.4.0 Guidance for rapporteurs - Selection criteria and list of interoperability-based cryptographic mechanisms

<mark>Editor’s note for rapporteurs: This clause provides guidance for selecting interoperability-based cryptographic mechanisms 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 interoperability-based cryptographic mechanisms, where any, have been identified in clause K.4.2.</mark>

When preparing the list of interoperability-based cryptographic mechanisms in clause K.4.2, the following criteria guide the selection of candidate interoperability-based cryptographic mechanisms. The criteria are cumulative: a cryptographic mechanism is to be included in clause K.4.2 only where all applicable criteria below are fulfilled:

- a) the cryptographic mechanism is not claimed as ACM-extended under clause K.1.1 item 2 and is either not listed in the ACM catalogue or is subject to an ACM deprecation date, expiry date, migration condition, usage limitation, or other ACM indication that prevents its use as a state-of-the-art cryptographic mechanism for the relevant product function;

- b) the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including \[list of organisations\];

- c) the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;

- d) the cryptographic mechanism is required for a specific set of product functions to comply with a well-defined external specification or external requirement;

- e) the use of the cryptographic mechanism is subject to conditions or limitations that prevent it from being used beyond the identified interoperability need, where applicable.

> NOTE 1: For the treatment of cryptographic protocols and their underlying cryptographic primitives, modes of operation, constructions, parameter sets and cipher suites, see clause K.1.1 and its notes.

> NOTE 2: Cryptographic mechanisms listed in this clause are used to support the application of clause K.1.1 item 3).

> NOTE 3: Inclusion of a cryptographic mechanism in this clause does not classify that mechanism as state-of-the-art cryptography.

> NOTE 4: In this clause, an external requirement can be a regulatory requirement, a mandatory public-sector requirement, an operational constraint, a technical interoperability constraint, or a platform compatibility requirement requiring the use of a specific cryptographic mechanism for interoperability with an identified system, platform or operational context.

> NOTE 5: For interoperability-based cryptographic mechanisms, specifying conditions or limitations is necessary to support the secure and constrained use of mechanisms that are not classified as state-of-the-art cryptography and to prevent such mechanisms from becoming the de facto default where a state-of-the-art mechanism is applicable. Such conditions or limitations include, for instance, permitted or excluded use cases, specific configurations, identification of the external system, external specification or external requirement requiring use of the mechanism, preference for ACM-listed or ACM-extended mechanisms during negotiation where applicable, compensating measures, migration details, warning or logging requirements, or lifecycle limitations. If such conditions or limitations cannot be applied for technical reasons specific to the product category, the reason is to be documented in the vertical standard.

### K.4.1 Requirement

Where the product’s default configuration uses interoperability-based cryptographic mechanisms, these mechanisms shall be selected from the interoperability-based cryptographic mechanisms listed in clause K.4.2 for the specified product functions and external specifications or external requirements and shall be used in accordance with the conditions or limitations specified in clause K.4.2.

|:-----------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------|:--------------------------------------------------------------------------|:-----------------------------------------------------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

| \<mechanism name\>                             | \<Algorithm / Primitive / Scheme / Protocol / Protocol profile / Cipher suite / Mode / Construction / Parameter set / Other\> | \<key length, mode, profile, cipher suite, parameter set, version, etc.\> | \<product function, interface, protocol context, operational context, etc.\> | \<external specification, regulatory requirement, mandatory public-sector requirement, operational constraint requiring use of the mechanism, technical interoperability constraint, platform compatibility requirement, etc.\> | \<why the mechanism is needed for interoperability\> | \<constraints, permitted use, excluded use, negotiation preference, external system or requirement, compensating measures, migration expectation, warning/logging, lifecycle limitation, etc.\> |

<mark>Editor’s note for rapporteurs: Where no interoperability-based cryptographic mechanisms are specified by the vertical standard, this clause should state: “No interoperability-based cryptographic mechanisms are specified.” This editor’s note shall be removed before publication.</mark>

<mark>Editor’s note for rapporteurs: Table K.2 is an example template and can be adapted where needed for the relevant vertical standard.</mark>

### K.4.3 Assessment

Compliance with the requirement in clause K.4.1 is assessed in clause K.1.2.3.