# Annex K (normative): Generic requirements and assessment criteria for the use of state of the art cryptography V 0.51 (2025-02-16)
ETSI Drafting rules do not allow footnotes. All footnotes in this Annex will have to be deleted or replaced by relevant references and notes before publication.
Note for Gisela, Clauses have been renumbered for consistency.
## K.1 State of the Art Cryptography (SOTA)
### K.1.1 Requirement
The product shall, by default, use State-of-the-Art cryptography algorithms listed in (CRY-SOTA), to be used
for the supported security mechanism of the product where applicable.
NOTE 1: The use of security mechanism e.g. authentication, access control, secure communication,
secure storage and secure update are described in the main text of this standard.
NOTE 2:Cryptographic algorithm primitives (in short, algorithms e.g. public- and private-key
encryption algorithms, hash functions, authentication codes, digital signatures) are classified as CRY-SOTA if
they are listed in the [ACM]1 document and are suitable for the implementation of supported security
mechanisms of the product.
The product shall, by default, use State-of-the-Art cryptography algorithms listed in (CRY-SOTA), to be used for the supported security mechanism of the product where applicable.
> NOTE 1: The use of security mechanism e.g. authentication, access control, secure communication, secure storage and secure update are described in the main text of this standard.
> NOTE 2:Cryptographic algorithm primitives (in short, algorithms e.g. public- and private-key encryption algorithms, hash functions, authentication codes, digital signatures) are classified as CRY-SOTA if they are listed in the [ACM] document and are suitable for the implementation of supported security mechanisms of the product.
> NOTE 3 Supporting evidence options that an algorithm, which is not included in CRY-SOTA, is applicable and suitable for the respective use case, are listed in the related assessment criteria ( K.1.2.1) clause.
### K.1.2 Assessment criteria
#### K.1.2.1 Assessment objective:
The purpose of this assessment case is (the conceptual assessment) whether the implemented algorithms are identified as CRY-SOTA.
##### K.1.2.1.1 Assessment preparation:
##### K.1.2.2 Assessment preparation:
- Preconditions for the test: If applicable, the product is in the default- configuration. Otherwise, the product is in the delivery state, where it is available on the market in accordance with CRA Annex I part 1(2) (b).
##### K.1.2.2.2 Assessment activities:
- For every security mechanism the list of used algorithms, which are reachable over an interface and identified as CRY- SOTA shall be documented.
Supporting Evidence:
##### K.1.2.3 Assessment activities:
- For every security mechanism the list of used algorithms, which are reachable over an external interface and identified as CRY- SOTA shall be documented.
##### K.1.2.4 Supporting Evidence:
- description of the performed test
- all test records of the performed test Assignment of verdict:
- all test records of the performed test
##### K.1.2.5 Assignment of verdict:
- The verdict PASS shall be assigned if evidence has been provided.
- The verdict FAIL shall be assigned otherwise
If the verdict in K.1.2.1 has been assigned FAIL, the following assessment has to be performed additionally:
1 [ACM] ENISA_Report_1747792503 European Cybersec
##### K.1.2.2 Assessment objective:
##### K.1.2.5.1 Assessment objective:
If for a certain security mechanism and use case no CRY-SOTA algorithm is applicable, evidence shall be
provided in the documentation that a suitable algorithm has been implemented for this evidence instead.
###### K.1.2.2.1 Assessment preparation:
###### K.1.2.5.2 Assessment preparation:
- Preconditions for the test: If applicable, the product is in the default configuration state. Otherwise, the product is in the delivery state, where it is available on the market in accordance with CRA Annex I part 1(2) (b).
###### K.1.2.2.2 Assessment activities:
###### K.1.2.5.3 Assessment activities:
For every security mechanism and for every used algorithm, which is reachable over an interface of the product and identified as not included in CRY- SOTA, the documentation shall provide evidence:
- that this algorithm is applicable and suitable for the respective use case
- that no CRY-SOTA algorithm is applicable otherwise
Supporting Evidence:
- that no CRY-SOTA algorithm is applicable // DO WE KEEP THIS? (GDC)
###### K.1.2.5.4 Supporting Evidence:
- 1. Identification of the certain algorithm by reference in further algorithm catalogues as national cryptographic catalogues 2 or vertical use case specific cryptographic algorithm catalogues
- 2. Alternatively, description and formal verification or cryptographic security proof of a new algorithm
- 2. No entry of known exploitable vulnerabilities provided in ENISA “European Vulnerability Database.
- Description of the performed test
- all test records of the performed test
Assignment of verdict:
###### K.1.2.5.5 Assignment of verdict:
- The verdict PASS shall be assigned if respective evidence has been provided,
- The verdict FAIL shall be assigned otherwise.
NOTE 3: Functional correctness and completeness assessment criteria of the documentation are to be
specified in accordance with the capabilities set in the specific vertical Standards.
> NOTE 3: Functional correctness and completeness assessment criteria of the documentation are to be specified in accordance with the capabilities set in the specific vertical Standards.
## K.2. Requirement (“crypto agility”)
Where applicable the product shall by default be prepared to update cryptographic algorithm used for the supported security mechanism of the product to maintain when there are indications that the used cryptographic
algorithm will not stay SOTA anymore within the intended lifetime of the product.
