@@ -3318,7 +3318,28 @@ For every security mechanism identified under the preceding clause, the assessor
3. inspect the product in the configuration identified under the preceding clause and confirm that the cryptographic algorithm and parameters in use match the documented configuration;
4. where the manufacturer has documented the use of an algorithm that is not classified as CRY-SOTA under any path of clause K.1, verify that the conditions for legacy interoperability are met.
### 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.
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.
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.
4. Where the catalogue referenced under path ii) does not provide a lifecycle classification, the manufacturer shall document the algorithm’s expected deprecation date based on the published cryptanalytic state of the art.
- NOTE 1: The ACM catalogue references a number of cryptographic specifications published as ISO/IEC standards. Where such referenced specifications exist, technically equivalent specifications published in publicly available form (for example as IETF RFCs, as NIST Special Publications, or as IEEE standards) can also be cited as evidence under path ii) of clause K.1.
- NOTE 2: The reference catalogues identified under K.1.1 (ii) use a range of lifecycle terminologies (for example "Recommended" / "Legacy" / "Deprecated" in the ACM; "Acceptable" / "Disallowed" in NIST SP 800-131A [5]; "Recommended" / "Legacy use" in BSI TR-02102-1 [2]).
- NOTE 3: The supplemental check under (3) above is intended to capture the case where a cryptographic primitive listed in a catalogue is nevertheless subject to a fundamental break that has not yet been reflected in catalogue revisions. Vulnerability database entries typically catalogue implementation defects in specific products, which are not in themselves a basis for declassifying an algorithm.
