Editorial changes to the Clause 5

| Use-case | Requirement set | required level |

| :------- | :-------------- | -------------- |

| all      | CYB_GENERAL     | all            |

|          | CYB_GENERAL     | low            |

|          | CYB_GENERAL     | medium         |

|          | CYB_GENERAL     | high           |

| all      | CYB_OPS         | all            |

| all      | KEV_EXPLOIT     | all            |

| all      | SBD_TECH        | all            |

| all      | CON_INGEST      | all            |

| all      | CON_CRYPTO      | all            |

| all      | CON_CHANNEL     | all            |

| all      | INT_CONF        | all            |

| all      | INT_ROTATE      | all            |

| all      | DM_RETENTION    | all            |

|          | IM_SEGMENT      | low            |

|          | IM_SEGMENT      | medium         |

|          | IM_SEGMENT      | high           |

| all      | MAS_TECH        | all            |

| all      | MON_LOG         | low            |

| all      | MON_LOG         | medium         |

| all      | MON_LOG         | high           |

## 5.2 Appropriate level of cybersecurity

<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>

For low risk:

* **SBD_TECH-3** The product shall implement **CON_CRYPTO-1** in all interfaces, expect the ones that are available and reachable only in localhost by the local processes.

* **SBD_TECH-4** When privileged information is transferred or accessed, a [5.7.2 Secure channel](#572-secure-channel) shall be used in transport.

* **MON_LOG-1** The log data of events shall be protected from unauthorised access.

* **MON_LOG-2** The log data of events shall be protected from modification including their deletion.

* **MON_LOG-3** The log data of events shall be confidentiality protected.

* **MON_LOG-4** The log information shall include the following fields including, but not limited to, event time, actor identity, action type, and affected non-sensitive scope and object identifiers.

* **MON_LOG-5** The product shall log all received relevant events from its managed elements including, but not limited to, incidents, alarms, time shift alarms.

* **MON_LOG-4** The log information shall include the following fields including, but not limited to:

  * event timestamp

  * actor identity

  * action type

  * affected non-sensitive scope

  * and object identifiers.

* **MON_LOG-5** The product shall log all received relevant events from its managed elements including, but not limited to:

  * incidents

  * alarms

  * time shift alarms.

The following requirements apply where the corresponding function exists:

Fulfilment of these requirements is essential for all products in all use cases and all risk levels.

Breaches can not be detected, if an attacker can hide it's existense.

General requirements:

General requirements that are unconditionally applicable:

* **MON_METRICS-1** The product shall be designed in a way that collected and stored metrics data can not be altered.

* **MON_METRICS-2** Historical metrics data import overwriting an existing data point shall be noticed.

> NOTE: **MON_METRICS-3** leaves open how the information is conveyed to the product user. It could be a dedicated portal within the product or machine readable output having the same information.

Availability, uptime, and application metrics requirements:

Availability, uptime, and application metrics requirements that are applicable where defined operational environment or protocol makes it possible:

* **MON_METRICS-4** The product shall collect, track and store metrics on, including, but not limited to:

  1. availability and status changes, like process and service crashes and restarts

  2. incidents

  2. incidents, warning and notification events reported by the target

  3. relevant operative information like CPU, memory, disk utilisation

  4. relevant networking metrics like throughput and protocol errors

  5. relevant databases and storage health metrics like queries per second, latency and throughput

The **MON_METRICS-4** is defined expecting that the product hosts these services.

When RDPS is used for these functions, the relevant metrics are different and "like queris per second" equivivalent can be used.

> NOTE: Relevancy of the metric depends on the protocols in use, the product design and the operative environment makes available.

What metrics and logs can be collected is defined in more detail in [5.9 Data minimisation](#59-data-minimisation).

## 5.15 Factory reset and data portability

This clause provides objective and reproducible assessment criteria to determine whether a product complies with the technical security requirements of clause 5.

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

<mark>Editor’s note: 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.</mark>

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

* **Assessment reference:** Refers to the identifier of the concerned technical requirement.\

  <mark>Editor’s Note: Ideally, the reference is formatted also as a link to the corresponding technical requirement clause, allowing readers to jump to that section (and back).</mark>

* **Assessment objective:** Defines the security property or capability that shall be verified, ensuring that the assessment remains focused on the intent of the requirement.

* **Assessment preparation:** Describes the environment, setup, and preconditions required before executing the test with a view to guaranteeing consistent evaluation results. 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 analysers, static code analysers, cryptographic test suites).\

  <mark>Editor’s Note: Precisely reference individual tools or include an unambiguous characterisation by way of tool capabilities to ensure consistent tool application. For instance, “state-of-the-art vulnerability scanner” shall instead be replaced with “vulnerability scanner that covers all CVEs, supports credentialed and non-credentialed scans, ...”</mark>\

  <mark>Editor’s Note: The standard shall not discourage the use of paid security products to comply with requirements by mandating specific free tools where other options are equally suitable. In such cases, the free tools can be listed informatively, but the general capabilities required of the tool should be listed normatively.</mark>

  * 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 such that the same assessment verdict would be reached when repeating these steps now or at a later point in time. 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).\

  <mark>Editor’s Note: Checking documentation for the presence or absence of certain security controls should be the last resort or only a supporting activity, with strong preference given to actual verification of security qualities of the product by testing the final product or its source code.</mark>

  * 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;

<mark>Editor’s note: The assessment criteria shall be indexed, to facilitate their referencing.</mark>

<mark>

Proposed structure for indexing the assessment criteria:

<br>

ACC - PP - ESR - NNN

<br>

ACC: Used to identify assessment and compliance criteria in the text

<br>

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

<br>

ESR :Proposed abbreviations referring to the different essential requirements of the regulation

<br>

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

</mark>

## 6.2 Appropriate level of cybersecurity

### 6.2. REQ-GEN-2

#### 6.14.1.10 MON_LOG-10

**Objective:** Reduces vendor lock-in and supports incident response and CRA evidence portability.

**Objective:** Reduces vendor lock-in and supports incident response and evidence portability.

**Preparation:** None<br/>

**Activities:** None<br/>

**Verdict:**

1. Pointers to the documentation.

#### 6.14.1.12 REQ-LOG-12

#### 6.14.1.12 MON_LOG-12

**Objective:** Enables audit replay and accountability for automated control planes. Reduces ambiguity in incident investigations.

**Preparation:** None<br/>