Clause 5 and 6 structure update and NKEV requirements updates

- **UC3**: Open or public PKI for Certificate Authorities (CA).

- **UC4**: Multi-authority PKI.

<mark>Each use case should clearly specify the users and privileges associated to each user. Details of these rights and privileges for each use case are given in Annex … In addition each use case should specify any constraints on the persistence of relationships, access or use of assets.</mark>

### 4.6.1 Product for use in Private PKI

In such organisations the PKI may be organised on department centric hierarchies, or on location centric hierarchies, or on organisation role hierarchies or some combination of these. Whilst the set of services to be enabled by the PKI in this use case are large they may include VPN access and management, timestamp services, disk or message encryption, email. and document access and distribution and so on. The deployment of such a private Public Key Infrastructure (PKI) is not driven by regulatory or standardized requirements but rather by the need to align with the entity’s internal policies and security practices.

Additionally, users of these PKI solutions often prioritize flexibility and ease of use over highly secure but restrictive technologies. For instance, they will not rely on secure cryptographic devices but rather have private keys stored using operating system or platform key management facilities that provide protection against unauthorised access at rest. The manufacturer shall document the protection mechanisms relied upon and their limitations. Where the platform facility supports hardware-backed protection (e.g. TPM), this should be the preferred configuration.

### 4.6.2 Product for use in Critical entity PKI

> - EXAMPLE: eIDAS

As a result, users of these PKI solutions do not have the same deployment flexibility as in less regulated use cases (e.g., UC1). However, they are still permitted to use PKI products that offer diverse functionalities.

### 4.6.3 Product for use in Public CA PKI

PKI product used to support certification services provided within very large multi-site company or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of remote or unknown users, other products, networks or services, or to the health, security or safety of the public.

### 4.6.4 Product for use in multi-authority PKI

In general terms the multi-authority model separates the entity responsible for authentication from the entity responsible for authorisation of specific services, in like manner to the model of Kerberos [[i.5](#_ref_i_5)] but applied to a public key system.

<mark>The use cases may be defined by a combination of the product context elements described in clauses 4.1 to 4.5.</mark>

### 4.7.1 Private PKI for non-critical entities

#### 4.7.1.1 Assets

</div>

#### 4.7.1.2 Threats

##### 4.7.1.2.1 System administration

| T_SYS15.Denying system administrator access via an unprotected remote <br>administration interface | SYS21 | Availability |

| T_SYS16.Accessing system administration functions via an unprotected <br>local administration interface | SYS22 | Integrity,<br>Availability,<br>Traceability |

<br />

</div>

 | T_REG09.Denying system operator access via an unprotected registration <br>user interface | REG21 | Availability |

 | T_REG10.Denying subscriber access via an unprotected certificate request API | REG22 | Availability |

<br />

</div>

The CA should enforce separation between trusted roles with conflicting responsibilities such as system operators and system auditors.

### 4.7.3 C-ITS PKI

A Public Key Infrastructure (PKI) dedicated to Communicating Intelligent Transport Systems (C-ITS) is used to manage ITS related certificates  to enable deployment of security functions over the different components of ITS systems, mainly signature and encryption of ITS messages. The PKI is responsible for the issuance, revocation, and overall management of certificates and certificate status information.

The PKI architecture and its functionalities considered here are the one standardized by the ETSI in ETSI TS 102 940 and ETSI TS 102 941.

The C-ITS PKI should provide the different services required by the RCA, EC and AA roles defined by the European C-ITS trust model. In the figure we also identify the role of a Misbehaviour Authority (MA): entity responsible to receive misbehaviour reports coming from ITS-S identifying other misbehaving ITS and emits action requests to the other C-ITS PKI authorities to react to misbehaving behaviour of ITS-S.

### 4.7.4 Machine to Machine PKI

# 5  Requirements for PKI products

# 5 Technical requirements for the Products

## 5.1 Introduction - Applicability of the requirements

The technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The equipment shall comply with all applicable technical requirements of the present document at all times when operating in such product context.

The applicability of the requirements to the Use Cases / Security Profiles are defined below:

## 5.2 No known exploitable vulnerabilities

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a).

REQ-PKI-KEV-01: The product shall not contain known exploitable vulnerabilities, unless vulnerability assessment demonstrates that:

    • the vulnerability is not exploitable in the product; or

    • specific user guidance is provided to prevent exploitation.

NOTE: Details of the vulnerability assessment are provided in the vulnerability handling process defined in prEN 40000-1-3 [\[2\]](#_ref_2).

## 5.3 Secure by default configuration

_Proposed ESR code SBD_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).

REQ-PKI-SBDC-001: All assets of the system shall be defined as protected assets with default access condition of DENY.

NOTE 1:	See also clause 5.5.

EXAMPLE:	The role of the access control countermeasure is described in ETSI TS 102 165-2 [] (clause 6) where permission to access a resource is only ever true (PERMIT) or false (DENY) and where the decision to give permission is always deterministic.

## 5.4 Secure updates

_Proposed ESR code: SU_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).

## 5.5 Authentication and access control

_Proposed ESR code: AAC_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (d).

## 5.6 Confidentiality

_Proposed ESR code: CON_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (e).

<mark>Editor's Note:In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography.</mark>

## 5.7 Integrity

_Proposed ESR code: INT_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).

## 5.8 Data minimisation

_Proposed ESR code: DM_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (g).

## 5.9 Availability protection

_Proposed ESR code: AP_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).

## 5.10 Impact minimisation

_Proposed ESR code: IM_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).

## 5.11 Minimisation of attack surfaces

_Proposed ESR code: MAS_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).

## 5.12 Exploitation mitigation mechanisms

_Proposed ESR code: EMM_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (k).

## 5.13 Logging and monitoring

_Proposed ESR code: LOG_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (l).

## 5.14 Data removal and transparency

_Proposed ESR code: DRT_

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (m).

## 5.15 Vulnerability handling

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 2.

The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be fulfilled for the product.

# 6 Assessment criteria for compliance with technical requirements

_It has been agreed across vertical standards to define each assessment criteria following the common structure:_

- _Requirement reference_

- _Objective_

- _Preparation_

- _Activities_

- _Verdict_

- _Evidence_

_The assessment criteria clause shall be structured by requirement defined in clause 5._

## 6.1 Introduction to the assessment and compliance criteria

This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5, based on the UC and/or the Security Profile it may belong towards its placement in the EU market.

For each cybersecurity requirements defined in Clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.

Please ensure that there is an easy, clear and unambiguous mapping of the requirements in clause 5 to the relevant assessment criteria in clause 6.

The assessment criteria for each security requirements are described in a structured manner, as follows:

- **Assessment objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement. It includes the reference index of the requirement(s) it aims to assess.  

- **Assessment preparation:** Describes the environment, setup, and preconditions required before executing the test. It includes the following elements as applicable:

    - Test environment: Describe the hardware, software, and network setup used for the assessment, including versions, topology, and any relevant dependencies.

    - Preconditions: Specify any configurations, credentials, or operational states that should be established before the test (e.g. product initialized, certificates loaded, user roles created).

    - Required tools: Identify the tools or software necessary to perform the assessment (e.g. vulnerability scanners, protocol fuzzers, traffic analyzers, static code analyzers, cryptographic test suites).

    - Required information/documentation for the assessment: Specify all information that is necessary to perform the assessment

    - Reference any vendor-provided setup guides, configuration instructions, or operational manuals, as well as any relevant standards or technical notes, that define how the product shall be configured or operated for the assessment.

- **Assessment activities:** Provides execution steps to be performed. Assessment activities may include, as applicable:

    - Review information/documentation for the assessment to confirm that the described implementation matches the requirement (e.g. verify that the security architecture document specifies TLS 1.2 or higher for all external interfaces, or that the password policy aligns with the defined threshold).

    - Perform security functional tests to verify the completeness and correctness of the information/documentation for the assessment

    - Perform security functional or penetration tests to verify that implemented controls are correctly implemented e.g. to prevent unauthorized access or data modification (e.g. via attempting to log in with invalid credentials to test lockout enforcement or trying to modify protected configuration files without administrative privileges).

    - Analyse code or binaries to identify potential security weaknesses or misconfigurations (e.g. perform static analysis to detect hardcoded credentials or use dynamic analysis tools to identify buffer overflow or injection vulnerabilities).

    - Inspect configurations to ensure that required security parameters are correctly applied (e.g. check that weak cipher suites are disabled, two-factor authentication is enabled, and least-privilege access controls are configured in the system).

    - Observe runtime behaviour to confirm that protections such as encryption, authentication, and integrity verification operate as intended (e.g. monitor network traffic to ensure data in transit is encrypted or observe system logs to verify successful validation of digital signatures during startup).

- **Assessment verdict:** Defines the pass/fail criteria.

    - **Pass:** The assessment is considered passed if the product demonstrably fulfils the requirement and meets the defined security thresholds. Examples of such thresholds include:

        - Minimum cryptographic strength (e.g. AES-128 or higher);

        - Password policy limits (e.g. minimum of 12 characters);

        - Login protection mechanisms (e.g. account lockout after five consecutive failed attempts);

        - Resistance to a specified attack potential (e.g. equivalent to CSA High/AVA\_VAN.3 or higher).

    - **Fail:** The assessment is considered failed if the requirement is not fulfilled, or if the defined security thresholds are not achieved (e.g. insufficient key length, missing authentication enforcement, or inadequate resistance to the required attack potential).

- **Assessment evidence** : Defines the artefacts and documentation  collected to demonstrate that the requirement has been assessed and fulfilled. The evidence shall be sufficient to enable independent verification of the assessment results and to demonstrate compliance with the relevant CRA essential requirements. The supporting evidence include, where applicable:

    - Test or assessment reports showing the steps performed and results obtained;

    - Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

    - Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;

    - Relevant vendor or design documentation describing the applied security measures;

_It would be very useful to use a common structure for the assessment criteria definition clause 6. The following is a proposal - to be discussed among rapporteurs._

_The assessment criteria shall be indexed, to facilitate their referencing, preferably using a common indexing structure throughout all standards and enabling an easy mapping with the requirements of Clause 5._

_Proposed structure for indexing the assessment criteria:_

_ACC - PP - ESR - NNN_

_ACC: Used to identify assessment and compliance criteria in the text_

_PP : Product short name added only if relevant when the product category may be divided in sub categories_

_ESR :Proposed abbreviations referring to the different essential requirements of the regulation_

_NNNNN - Incremental and unique sequence of numbers and letters - could be the same as for the corresponding requirement (if one-to-one match), otherwise a mapping would be needed_

- REFERENCE: ASS-REQ-6.4-08

  - OBJECTIVE: XXX

  - PREPARATION: XXX

  - ACTIVITIES: XXX 

  - VERDICT:

  - EVIDENCE:

## 6.2 No known exploitable vulnerabilities

- REFERENCE: ASS-REQ-6.4-08

  - OBJECTIVE: Verify that:

    1. Known exploitable vulnerabilities affecting the product are identified.

    2. For each identified known exploitable vulnerability, one of the following applies:

       the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or

       specific user guidance is provided to prevent exploitation.

    3. No known exploitable vulnerability remains in the product without one of the above justifications.

  - PREPARATION:

    - [DESIGN] Product documentation identifying elements contained in the product (elements may include software, firmware, or hardware elements, as applicable).

    - [INVENTORY] component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available.

    - Access to the product, or to relevant components such as binaries, packages, images, firmware, containers, or file systems, sufficient to perform vulnerability scanning where technically feasible.

    - Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product.

    - Access to recognized public vulnerability sources:

        - Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD)) and relevant vendor advisories;

        - Complementary sources that may support identification of relevant vulnerabilities, where relevant, for example technical research papers, conference papers and other publicly available security research.

  - ACTIVITIES:

    - Review the product documentation, component inventory, bill of materials, or equivalent information to identify the elements contained in the product (which may include software, firmware, or hardware elements, as applicable) and their relevant versions or patch levels, where available.

    - Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting elements contained in the product.

    - Assess, in accordance with prEN 40000-1-3 [X], the vulnerabilities identified through correlation of scanning results, product identification information, vendor advisories, and recognized public vulnerability sources.

    - For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product:

    - Where the treatment of an identified known exploitable vulnerability relies on user guidance, review the user guidance and verify that it specifically addresses the conditions to prevent exploitation.

    - Verify that no identified known exploitable vulnerability affecting the product remains without:

       - a vulnerability assessment demonstrating non-exploitability in the product; or

       - specific required user guidance to prevent exploitation. 

  - VERDICT:

      - Pass: Known exploitable vulnerabilities affecting the product are identified, and each such vulnerability is covered either by a vulnerability assessment demonstrating non-exploitability in the product, or by specific user guidance preventing exploitation.

      - Fail: Vulnerability assessment is missing or insufficient for one or more such vulnerabilities, user guidance is missing or inadequate where relied upon, or one or more known exploitable vulnerabilities remain without justified treatment.

  - EVIDENCE:

    - [SCAN] Vulnerability scanning results, including the tools and vulnerability databases used.

    - [ADVISORY] Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment.

    - [ANALYSIS] Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3 [X].

    - [GUIDANCE] Product user guidance relied upon to prevent exploitation, where applicable.

## 6.3 Secure by default configuration

## 6.4 Secure updates

## 6.5 Authentication and access control

## 6.6 Confidentiality

## 6.7 Integrity

## 6.8 Data minimisation

## 6.9 Availability protection

## 6.10 Impact minimisation

## 6.11 Minimisation of attack surfaces

## 6.12 Exploitation mitigation mechanisms

## 6.13 Logging and monitoring

## 6.14 Data removal and transparency

## 6.15 Vulnerability handling

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be met for the product

## 5.1 Auditing