@@ -3320,18 +3320,21 @@ For every security mechanism identified under the preceding clause, the assessor
### K.2.4 Assessment evidence
1. For each cryptographic algorithm in use, a reference to a publicly available catalogue entry or to the relevant clause of the present document, in accordance with one of the paths of clause K.1. Acceptable references include:
- a) the entry in the ACM catalogue (path i);
- b) the entry in any of the recognized catalogues listed under K.1.1 (ii) (path ii); for example a national cryptographic catalogue published by a Member State authority, a sector-specific catalogue published by a recognized standards-development organization, or an industry catalogue, where the catalogue is publicly available and is maintained under a documented revision and retirement process;
- c) the clause of the present document listing the algorithm as part of the vertical-specific cryptographic content for routers, modems and switches (path iii);
- d) where an algorithm is referenced under path ii) or path iii) but is not present in the ACM, the documentation shall in addition identify the publicly available specification (e.g. an IETF Request for Comments, an IEEE standard, an ETSI deliverable, a NIST publication) under which the algorithm is implemented.
[loweralpha]
. the entry in the ACM catalogue (path i);
. the entry in any of the recognized catalogues listed under K.1.1 (ii) (path ii); for example a national cryptographic catalogue published by a Member State authority, a sector-specific catalogue published by a recognized standards-development organization, or an industry catalogue, where the catalogue is publicly available and is maintained under a documented revision and retirement process;
. the clause of the present document listing the algorithm as part of the vertical-specific cryptographic content for routers, modems and switches (path iii);
. where an algorithm is referenced under path ii) or path iii) but is not present in the ACM, the documentation shall in addition identify the publicly available specification (e.g. an IETF Request for Comments, an IEEE standard, an ETSI deliverable, a NIST publication) under which the algorithm is implemented.
2. Where a non-CRY-SOTA algorithm is offered by the product to support interoperability with a specifically identified legacy system, in accordance with recital (55) of Regulation (EU) 2024/2847 [i.1] and section 2.5 of the Commission Guidance on its application, the documentation shall demonstrate that all of the following conditions are met:
a) the non-CRY-SOTA algorithm is not used in the default or delivery-state configuration;
b) where the relevant security mechanism supports algorithm negotiation, a CRY-SOTA algorithm is offered and is preferred over the non-CRY-SOTA algorithm during negotiation;
c) the documentation identifies the specific legacy system or systems for which the non-CRY-SOTA algorithm is required, and the legacy constraint that prevents use of a CRY-SOTA alternative;
d) the documentation declares a sunset date for the non-CRY-SOTA algorithm that falls within the declared intended lifetime of the product;
e) a user-facing indication (such as a log entry, a management-interface warning, or an equivalent mechanism) informs an administrator when the non-CRY-SOTA algorithm is in use.
[loweralpha]
. the non-CRY-SOTA algorithm is not used in the default or delivery-state configuration;
. where the relevant security mechanism supports algorithm negotiation, a CRY-SOTA algorithm is offered and is preferred over the non-CRY-SOTA algorithm during negotiation;
. the documentation identifies the specific legacy system or systems for which the non-CRY-SOTA algorithm is required, and the legacy constraint that prevents use of a CRY-SOTA alternative;
. the documentation declares a sunset date for the non-CRY-SOTA algorithm that falls within the declared intended lifetime of the product;
. a user-facing indication (such as a log entry, a management-interface warning, or an equivalent mechanism) informs an administrator when the non-CRY-SOTA algorithm is in use.
3. As a supplemental verification, not sufficient on its own, the manufacturer shall identify whether any entry in the ENISA European Vulnerability Database (EUVD) [i.17], in the Single Reporting Platform (SRP) [i.18] established under Regulation (EU) 2024/2847 [i.1], or in equivalent publicly accessible cryptanalytic literature, identifies a fundamental cryptanalytic break of the algorithm in use (as distinct from an implementation defect in a specific product). Where such a break is identified, the algorithm shall not be classified as CRY-SOTA notwithstanding any catalogue listing.
