Update after meeting review.

- <span id="_ref_1"></span><a name="_ref_1">[1]</a> \"ITU-T X.509\" \"(10/2019)\": \"Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks\"

  - NOTE:	Identical text in the defining of public-key and attribute certificates is also available in ISO/IEC 9594‑8 (paywall).

Editor's   - NOTE: the normal convention appears to be to refer to X.509 (as the original source) but in some cases references are cited as ITU‑T X.509/ISO‑IEC 9594‑8. 

- Editor's NOTE: the normal convention appears to be to refer to X.509 (as the original source) but in some cases references are cited as ITU‑T X.509/ISO‑IEC 9594‑8. 

- <span id="_ref_2"></span><a name="_ref_2">[2]</a> \"CEN\" \"prEN XXX\":\"  Cybersecurity requirements for products with digital elements – Vulnerability Handling\"

- <span id="_ref_2"></span><a name="_ref_2">[2]</a> \"prEN 40000-1-3\": \"Cybersecurity requirements for products with digital elements – Vulnerability Handling \" [Version and date to be added upon its publication by CEN CENELEC]

- <span id="_ref_3"></span><a name="_ref_3">[2]</a>ENISA Report 1747792503: “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025

## 2.2 Informative references

-	**F.Certificate status service:** provides certificate revocation status information to relying parties.

Each component service shall require configuration and maintenance by system administrators.

Each component service shall ensure that configuration and maintenance is only performed by system administrators.

PKI products also usually support:

- **F.Logging of security events:** for example, account access attempts, product  configuration changes, and system warnings or errors.

  - APPLICABILITY:

- REFERENCE: 	REQ-5.1-02

  - REQUIREMENT: The PKI shall employ reliable time stamps.

  - REQUIREMENT: The audit record shall identify the timing source used to generate the timestamp. The timestamp shall be in the scope of the integrity protection of the audit record (to prevent manipulation of the time stamp after the event).

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

- REFERENCE: REQ-5.1-06

  - REQUIREMENT: The PKI shall prevent auditable events, except those taken by the auditor, if the audit log is full.

  - RATIONALE: The audit log being full should not allow for old audit records to be lost or future auditable events to happen without record.

  - RATIONALE: If the PKI system is properly deployed—with appropriate policies, effective system management, and regular log reviews—an overload of logs should be seen as a symptom of a potentially significant security issue. In such cases, corrective actions should be taken before operations return to normal. Meanwhile, a full audit log should never result in the loss of old audit records or prevent future auditable events from being recorded.

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY:

- REFERENCE: REQ-5.1-07

  - REQUIREMENT: The PKI shall periodically create an audit log signing event in which it computes a

digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature,

keyed hash, or authentication code shall be computed over, at least:

  - REQUIREMENT: The PKI shall periodically create an audit log signing event in which it computes a digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature, keyed hash, or authentication code shall be computed over, at least:

a) every entry that has been added to the audit log since the previous audit log signing event;

b) the digital signature, keyed hash, or authentication code from the previous audit log signed event.

The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.

b) the digital signature, keyed hash, or authentication code from the previous audit log signed event. The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.

  - RATIONALE: All entries of the audit log, and the order and exhaustivity of batches of entries should impact authenticity checks of the audit log.

  - NOTE: An audit log signing event shall be performed even if no entry was added to the audit log since the last one.

## 5.2 Secret management

TODO: (cannot apply to ALL created keys)

	- REFERENCE: 

	  - REQUIREMENT: The PKI shall only create key pairs or symmetric keys by means of a secure cryptographic device appropriate for this use.

	- REFERENCE: REQ-5.2-01

	  - REQUIREMENT: The PKI shall only create key pairs keys by means of a secure cryptographic device appropriate for this use.

	  - RATIONALE:

	  - NOTE:

	  - EXAMPLES:

	  - APPLICABILITY:

- REFERENCE: REQ-5.2-02

  - REQUIREMENT: The PKI shall not persistently store private or symmetric keys in plaintext form.

  - REQUIREMENT: The PKI shall not persistently store private keys in plaintext form.

  - RATIONALE:

  - NOTE: The PKI may store private keys in a secure cryptograhic device.

  - EXAMPLES:

  - APPLICABILITY:

- REFERENCE: REQ-5.2-03

  - REQUIREMENT: Public keys stored within the PKI, but not within a secure cryptographic device, shall be protected against undetected modification through the use of digital signatures, keyed hashes, or authentication codes.

The digital signature, keyed hash, or authentication code used to protect a public key shall be verified upon each access to the key. If verification fails, the PKI shall not:

  - REQUIREMENT: Public keys stored within the PKI, but not within a secure cryptographic device, shall be protected against undetected modification. If verification fails, the PKI shall not:

a) release the accessed public key to the caller; or

## 5.3 Certificate issuance

- REFERENCE: REQ-5.3-01

  - REQUIREMENT: The certificates issued by the certificate generation service shall comply with the X.509 standard [ITU-T X.509] or with the IETF RFC 5280 standard or with the IEEE 1609.2 standard.

  - REQUIREMENT: The certificates issued by the certificate generation service shall comply with the X.509 standard [ITU-T X.509] or with the IETF RFC 5280 standard or with the IEEE 1609.2 standard, and if known, to any extension or profile identified by the target systems' policy.

  - RATIONALE: This extends what is mandated by ETSI EN 319 411-1 and takes into account the C-ITS PKI use case.

  - NOTE:

  - EXAMPLES:

# 6 Conformity Assessment

*Editor's note: This section's structur is stable. The content is not stable.*

NOTE: If a requirement stated in the present document can be shown to have been assessed under any other relevant regulation (e.g. NIS2, eIDAS) then the evidence of that assessment may be provided together with the other CRA presumption of conformity evidences so no further assessment is required in that case.

## 6.1 Vulnerability handeling

The developer shall conform to the requirements defined in [\[2\]](#_ref.2).

| (2)(g)  | Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);| 5 |     |                                                |

| (2)(h)  | Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;| 5.1 5.2, 6.2 & 6.3 |     |                                                |

| (2)(i)  | Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks; | 5 & 6 |     |                                                |

| (2)(j)  | Be designed, developed and produced to limit attack surfaces, including external interfaces; | 5, 6 & Annex A |     |                                                |

| (2)(k)  | Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques; | 5, 6 & Annex A |     |                                                |

| (2)(j)  | Be designed, developed and produced to limit attack surfaces, including external interfaces; | 5, 6 & Annex B |     |                                                |

| (2)(k)  | Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques; | 5, 6 & Annex B |     |                                                |

| (2)(l)  | Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user; | 5.1 & 6.2 |     |                                                |

| (2)(m)  | Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.|5.8||                                                |

## C.2.3 Estimate Risks (Risk factors)

## C.2.4 Evaluate Risks

# Annex K (normative) [CRY] Cryptography

V 0.3 (2025-12-07)

This normative annex is intended to provide generic requirements and assessment criteria for the use of

state -of- the- art cryptography.

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

### 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:

- 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:

- description of the performed test

- all test records of the performed test 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:

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:

- 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:

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:

- 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

- Description of the performed test

- all test records of the performed test

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.

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

NOTE 4: To maintain SOTA for cryptographic algorithm within the intended lifetime of the product concepts to consider are crypto agility additional to the capability of updating cryptographic algorithms on the product in accordance to Secure Update and Secure Communication mechanism.

NOTE 5: The [ACM] listing has two classes of SOTA algorithms; Legacy mechanisms with an expiry date as defined in ACM, and Recommended mechanisms with no set expiry date.

NOTE 6: For products or components of products that cannot have their cryptographic algorithms updated for example if the implementation or part uses a hardware-based root of trust, it is important that the intended lifetime of the equipment does not exceed the recommended usage lifetime of the cryptographic algorithms used by the product. Thereby the implementation of an algorithm can include the specific implementation of their parameters

NOTE 7: If a component storing the algorithm or corresponding parameters of a main product is replaced

by a new component, the product is considered as a new product according to the New Legislative Framework

Blue Guide4 , if the replacement provides a substantial modification to the main product

### K.2.1 Assessment criteria

#### K.2.2.1 Assessment objective:

The purpose of this assessment case is (the conceptual assessment) whether the product is prepared to update

cryptographic algorithms for the supported security mechanism.

###### K.2.2.1.1 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.2.2.1.2 Assessment activities:

- For every used SOTA algorithm, which is reachable over an interface, the life span of the algorithm is

documented, as well its property, if the algorithm is considered as legacy or recommended algorithm.5

- If the life span of the product exceeds the life span of a legacy algorithm, the algorithm is marked as

updatable by a recommended algorithm in the documentation.

- If an algorithm is identified as SOTA recommended, no further action is required.

###### K.2.2.1.3 Supporting Evidence:

- Description /documentation of the performed test.

- All test records of the performed test.

###### K.2.2.1.4 Assignment of verdict:

- The verdict PASS shall be assigned if respective evidence has been provided,

- The verdict FAIL shall be assigned otherwise

# Annex: Bibliography