Editorial: copyediting pass on 5.6-5.12

6. **trace**: record of a system status with all relevant data that can be gathered

7. **forward proxy server**: proxy server with intelligent web-caching and improvements of accelerating data transmissions combined with access controls

8. **managed element**: a physical or virtual device managed by the product

9. **cryptographic mechanism**: security-related procedure using cryptography

10. **cryptographic property**: property provided or supported by a cryptographic mechanism

9. **secure channel**: cryptographically protected communication channel

10. **cryptographic mechanism**: security-related procedure using cryptography

11. **cryptographic property**: property provided or supported by a cryptographic mechanism

> NOTE 1: The term “cryptographic mechanism” is used in the present document as an umbrella term covering the categories used in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\[1\]](#_ref_1), including cryptographic algorithms, primitives, schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.

> NOTE: A container hosting the product always has an operating system.

1. **REQ-KEV-01 (KEV_EXPLOIT-1)-1** The product shall have no known exploitable vulnerabilities, or

2. **REQ-KEV-01 (KEV_EXPLOIT-1)-2** the product shall not have any known exploitable vulnerabilities that were reported to within the previous 14 days, or the time period permitted before public disclosure as described in the vulnerability handling procedure for the product, or

3. **REQ-KEV-01 (KEV_EXPLOIT-1)-3** the product shall have no known exploitable vulnerabilities that do not have associated publicly-available documentation explaining the risk and how that risk has been mitigated.

* **KEV_EXPLOIT-1** The product shall:

  1. have no known exploitable vulnerabilities, or

  2. have no known exploitable vulnerabilities that were reported to within the previous 14 days, or the time period permitted before public disclosure as described in the vulnerability handling procedure for the product, or

  3. have no known exploitable vulnerabilities that do not have associated publicly-available documentation explaining the risk and how that risk has been mitigated.

> NOTE: An exploitable vulnerability's transition from “unknown” to “known” may be by its publication to the EU Vulnerability Database, an industry-specific vulnerability database, or direct notification to the manufacturer via its own vulnerability reporting process.

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

* **SBD_TECH-1** The product shall:

  1. **SBD_TECH-1-1** implement accepted cryptographic methods as described in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment) on all interfaces that are available or reachable outside of localhost within the local processes, and

  2. **SBD_TECH-1-2** by default only enable cryptographic mechanisms listed in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment)

  1. implement accepted cryptographic methods as described in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment) on all interfaces that are available or reachable outside of localhost within the local processes, and

  2. by default only enable cryptographic mechanisms listed in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment)

* **SBD_TECH-2** The product shall:

  1. **SBD_TECH-2-1** exclusively use interoperability-based cryptographic mechanisms as described in [clause K.4](k.4-interoperability-based-cryptographic-mechanisms), and

  2. **SBD_TECH-2-2** provide a user notification or other informative function when using such methods, and

  3. **SBD_TECH-2-3** inform the user which component requires the backwards compatible mechanism, and

  4. **SBD_TECH-2-4** indicate an upgrade path to using more secure cryptography when available.

  1. exclusively use interoperability-based cryptographic mechanisms as described in [clause K.4](k.4-interoperability-based-cryptographic-mechanisms), and

  2. provide a user notification or other informative function when using such methods, and

  3. inform the user which component requires the backwards compatible mechanism, and

  4. indicate an upgrade path to using more secure cryptography when available.

    This requirement applies to the subset of products that provide backward compatibility with cryptographic algorithms other than those listed in [clause K.3](#k.3-acm-extended-cryptographic-mechanisms).

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

* **SU_UPDATES-1** The product shall have the ability to receive security updates.

* **SU_UPDATES-2** The product shall have divorced OS and Application update procedures enabling the user to schedule the update following the operational needs and the High Availability targets.

* **SU_UPDATES-2** The product shall have independent OS and application update procedures enabling the user to schedule the update following the operational needs and the High Availability targets.

* **SU_UPDATES-3** The product shall by default attempt to install security updates at the time of first use to address all known exploitable vulnerabilities which were discovered after the product's placement on the market and before first use.

[//]: # (TODO note does not provide clarity)

#### Generic requirements

The product assigns to each subject a role or attributes based on the subject’s identity, to enable for the application of access control structures.

The access rights are thereby minimized to allow only for those operations that are needed for the intended use or task.

Access rights are thereby minimized to allow only for those operations that are needed for the intended use or task.

The assignment of access rights is the justification of the **AAC_AUTH-1** requirement, the matching of the control structure implementation with the intended use is covered with the requirement **AAC_AUTH-5**.

These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.

* **AAC_AUTH-1** The product shall support identity management through at least one of the following approaches:

    * integration of the product into an external state-of-the-art Identity Management System

    * integration of the product into an external state-of-the-art Identity Management System, or

    * integration of an external Identity Management System into the product, or

    * a dedicated Identity Management module built into the product.

* **AAC_AUTH-2** The product shall not implement a design where default credentials or keys are used to identify subjects.

* **AAC_AUTH-2** The product shall not allow for default credentials or keys to be used to identify subjects.

* **AAC_AUTH-3** The product shall use multi‑factor authentication to authenticate system users.

* **AAC_AUTH-4** The product shall limit a system user's authorisation validity of a session via a configurable setting that shall be initially limited by the factory default of one day.

* **AAC_AUTH-5** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.

* **AAC_AUTH-6** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.

* **AAC_AUTH-7** Privileged interfaces shall be protected with [5.7.1 State-of-the-art cryptographic libraries](#571-state-of-the-art-cryptographic-libraries).

* **AAC_AUTH-8** The product shall report all relevant events related to authorisation including, but not limited to:

    * successful and unsuccessful use of identity

    * object access

    * policy change

    * privileged function use

    * data access and deletions

* **AAC_AUTH-4** The product shall limit a system user’s session validity duration via a configurable setting that shall initially be limited by a default of, at maximum, one day.

* **AAC_AUTH-5** The authorization model shall enforce separation of privileges appropriate to the use case.

* **AAC_AUTH-6** The product shall subject access to privileged interfaces, control functions, and sensitive operations to strong authentication of subjects, services, or integrated components.

* **AAC_AUTH-7** The product shall protect privileged interfaces with [5.7.1 State-of-the-art cryptographic libraries](#571-state-of-the-art-cryptographic-libraries).

* **AAC_AUTH-8** The product shall report all relevant events related to authorisation including, at minimum:

    * successful and unsuccessful use of identity,

    * object access,

    * policy change,

    * privileged function use,

    * data access and deletions, and

    * data changes and permission changes.

* **AAC_AUTH-9** The product shall explicit authorise any privileged action before its execution can modify, including but not limited to:

* **AAC_AUTH-9** The product shall explicitly authorise any privileged action before its execution can modify, including, at minimum:

    * managed-element configuration

    * control-plane behaviour routing or forwarding state

    * security policy

    * software state

    * availability

    * network reachability.

* **AAC_AUTH-10** The authorisation decision shall be bound to, and made available in auditable event data, including but not limited to:

* **AAC_AUTH-10** The product's authorisation decision shall be bound to, and made available in, auditable event data, including but not limited to:

    * source of the identity

    * the acting identity

    * whether natural user or machine user

    * material request parameters

    * policy version or rule identifier

    * and validity interval.

* **AAC_AUTH-11** The product shall prevent the execution of any privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event, except the action aims to enable or restore auditability of the product.

* **AAC_AUTH-11** The product shall prevent the execution of any privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event, except where the action aims to enable or restore auditability of the product.

The requirement **AAC_AUTH-5:** is intentionally vague.

The model can be complex, and there can be multiple different overlapping mechanisms in place that can be used to enable the same function.

It can be built on top of existing authority structures, or it can re-run some parts of the device initialisation procedures.

How the retake of the authority is implemented is between the product and the device.

* **AAC_MACHINE-1** The product shall provide authentication for machine users such as certificates or tokens with an expiration date, mutual TLS with per-subject certificates, signed short-lived assertions/credentials like client assertions or workload identity, or equivalent asymmetric-key-based authentication; excluding static shared secrets and long-lived bearer tokens.

* **AAC_MACHINE-2** The privileged interfaces like APIs shall minimise access permissions for the machine user.

* **AAC_MACHINE-1** The product shall:

  1. provide authentication for machine users which does not involve passwords, such as certificates, tokens with an expiration date, mutual TLS with per-subject certificates, signed short-lived assertions/credentials like client assertions or workload identity, or equivalent asymmetric-key-based authentication, and

  2. exclude static shared secrets and long-lived bearer tokens as authentication methods for machine users.

* **AAC_MACHINE-2** The product shall minimize access for the machine user to privileged interfaces like APIs.

## 5.7 Confidentiality protection

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

* **CON_INGEST-1** The collected network element monitoring data shall be integrity and confidentiality protected.

* **CON_INGEST-2** The product shall cryptographically protect relevant data at rest and in transit, including but not limited to:

* **CON_INGEST-1** The product shall protect the confidentially and integrity of the collected network element monitoring data.

* **CON_INGEST-2** The product shall cryptographically protect relevant data at rest and in transit, including at minimum:

    * secrets

    * confidential configuration data

    * metrics that can expose confidential data

* **CON_INGEST-3** When data relevant to monitoring, control, or security functions is transferred over connections not controlled by the product, the product shall provide measures appropriate to the intended and reasonably foreseeable use to protect the integrity and, where required, the confidentiality of that data.

Products are delivered without known exploitable vulnerabilities and that comprises also implemented cryptography.

However, certain use cases or the product installation into a present user infrastructure may require the use of legacy protocols and cryptography.

As the product is delivered without known exploitable vulnerabilities, those legacy configurations cannot be the factory default setting, and may only be enabled after the user has been sufficiently informed about the security consequences.

* **CON_INGEST-3** The product shall provide measures appropriate to product use to protect the integrity and, where required, the confidentiality of data relevant to monitoring, control, or security functions that is transferred over connections not controlled by the product.

### 5.7.1 State-of-the-art cryptographic libraries

### 5.7.2 Secure channel

A **secure channel** used in transportation is a cryptographically protected communication channel.

When privileged information is transferred or accessed, the transport channel provides confidentiality, integrity protection, endpoint authentication, and protection against downgrading to less secure configurations.

TLS may be used for this purpose, but other mechanisms may also be used where they provide an equivalent level of protection and are implemented as defined in Annex K.

* **CON_CHANNEL-1** The product shall ensure that the secure channel uses cryptographic functions and configuration according to the Annex K.

* **CON_CHANNEL-2** All endpoints in a secure channel shall cryptographically verify others through mutual authentication.

* **CON_CHANNEL-2** Endpoints within the product shall cryptographically verify all other endpoints in a secure channel using mutual authentication.

![Figure 5.7.2-1: Secure channel example with TLS originated by managed element](./media/52_secure_channel_example.drawio.png)

### 5.8.1 Configuration integrity

* **INT_CONF-2** Where the product distributes or makes available configuration to managed elements the product shall ensure that

    * the configuration is protected against unauthorized modification and disclosure;

    * only the intended managed element can obtain the relevant configuration;

* **INT_CONF-2** The product shall ensure that:

  * product configuration is protected against unauthorized modification and disclosure, and

  * only the intended managed element can obtain the relevant configuration, and

  * the device can verify the integrity of the configuration.

    This requirement applies products that distribute or make available configuration to managed elements.

* **INT_CONF-3** The configuration interfacing design shall enable the managed element to cryptographically verify the authenticity of the product.

### 5.8.2 Cryptographic key initialisation and rotation

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

* **DM_RETENTION-1** The product shall define what is logged, and how long that record is kept by default, in group level accuracy like:

    * application debug output

    * application output labeled warning or critical

    * privilege escalations in the application operation

    * network configuration changes

* **DM_RETENTION-2** The product shall define what metrics are gathered, and how long that record is kept by describing at least, but not limited to:

* **DM_RETENTION-1** The product shall define what is logged, and how long that record is kept by default, in group level accuracy.

> EXAMPLE: group-level accuracy may resemble

> * application debug output

> * application output labeled warning or critical

> * privilege escalations in the application operation

> * network configuration changes

* **DM_RETENTION-2** The product shall define which metrics are gathered, and how long those records are kept by describing, at minimum:

    * metric name

    * metric description

    * metric cadence, if relevant for the collected metric

High availability starts from the running process.

In a modern cluster runtime environment used in large system deployments, the process rarely can control the loss of underlying resources.

Administrative actions can shutdown unexpectedly the node without a preceding announcement.

It is up to the software design whether or not such interruptions can be tolerated.

Administrative actions can unexpectedly shut down the node without a preceding announcement.

It is up to the software design whether such interruptions can be tolerated.

Modern design is often distributed, but depending on the implementation and runtime context, a singular process can also provide the targeted service availability, if the process was implemented correctly, and a self-healing system can launch a replacement within a given time window.

Following general risks apply if the product can be reached by a DDoS attack: For the product in large deployment scenarios, e.g. telecom or enterprise use cases, a DDoS is not practical due to the physical separation of payload network and management network.

For **medium** risk:

* **AP_HA-3** The product shall tolerate loss of resources within the limits of the defined availability.

[//]: # (TODO this belongs in 5.11)

* **AP_HA-4** The product shall minimise the impact to other systems when anomalies occur.

For **high** risk:

* **AP_HA-5** The product shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges, but also enforce active mitigation actions, including but not limited to connection throttling, temporary IP blocking, message buffering, and QoS parameterisation.

* **AP_HA-5** The product shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges, but also enforce active mitigation actions, including at minimum

    * temporary IP blocking, and

    * message buffering, and

    * QoS parameterisation.

* **AP_HA-6** The product shall implement recovery or failover mechanisms.

* **AP_HA-7** If the product can be exposed to DDoS, the product shall implement DDoS mitigations like:

* **AP_HA-7** The product shall implement DDoS mitigations including at minimum:

    * port switching

    * traffic redirections

    * service termination for a recommended and configurable time

    * disabling of the affected ports and interfaces for a configurable time

    This requirement applies to products which can be exposed to DDoS.

## 5.11 Non-interference

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

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

* **MAS_TECH-1** All communication interfaces of the product shall be documented;

  * the product shall not expose interfaces or initiate connections other than those documented;

  * interfaces not required for the intended use shall be disabled by default.

* **MAS_TECH-1** The product shall:

  1. document all communication interfaces, and

  2. not expose any interfaces or initiate connections other than those documented, and

  3. interfaces not required for the intended use shall be disabled by default.

* **MAS_TECH-2** The product shall not connect to undocumented RDPS services.

## 5.13 Exploit mitigation