Update to follow latest skeleton

## 5.1 Notes on the structure of requirements  (## 5.0 Introduction - Applicability of the requirements)

<mark>Editor's Note: This is the normative clause of the standard, defining the technical requirements to implement the Essential Cybersecurity Requirements of the CRA regulation.</mark>

<mark>Editor's Note: Requirements should be written with "shall" statements.</mark>

<mark>Editor's Note: Requirements should be on the product and should not establish a process. Consequently, it is not appropriate to state "the manufacturer shall xx". Lifecycle requirements are equally unacceptable.</mark>

<mark>Editor's Note: Requirements should only concern the essential requirements of the CRA (Annex I Part I) and no other legal obligations established in the CRA. Most notably, the standard should not mandate the manufacturer to perform a risk assessment or draft instructions and information to users. Documentation, however, can be used as part of the conformity assessment (the following Clause).</mark>

<mark>Editor's Note: The requirements shall be indexed, to facilitate their referencing, preferably using a common indexing structure throughout all standards.</mark>

<mark>Editor's Note: Proposed structure for indexing the requirements in ETSI deliverables:<br>

REQ-PP-[TECHNICAL-FAMILY]-NNN REQ: Used to identify requirement in the text<br>

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

TECHNICAL FAMILY :Proposed abbreviations referring to the technical domain covered by the requirement<br>

NNN - Incremental and unique sequence of numbers and letters

</mark>

<mark>Editor's Note: Requirements should be unambiguous regarding the preferred implementation, ensuring that specific security qualities of the product are achieved, the presence of which can be consistently and deterministically tested. Accordingly, vague or contextual requirements such as use of "state-of-the-art techniques" or "authentication mechanism" are not sufficiently granular. Instead, all viable concrete options shall be listed with a clearly indicated prioritization and potentially a selection process.</mark>

<mark>Editor's Note: It is strongly recommended to follow the sequence of the CRA Annex I requirements when defining the subclauses in Clause 5. However, where this structure would result in unnecessary duplication/overlap, subclauses and requirements may be organized in a more suitable way, provided that clear traceability to the relevant CRA Annex I requirements is maintained. A notable example of such an exception would be essential requirement (2)(b) on a secure-by-default configuration, which includes all configuration and thus also extends to the areas covered by other essential requirements.</mark>

<mark>Editor's Note: Where technical requirements rely on normative references to other standards, ensure those references are narrowly scoped, mapping out relevant clauses individually for larger sections and explaining the purpose of that content.</mark>

<mark>Editor's Note: Requirements should express one clear technical intent. Please divide technical requirements as much as needed to ensure this is the case.</mark>

<mark>Editor's Note: The cross vertical approach on RDPS should be followed as part of the technical requirements.</mark>

<mark>Editor's Note: Where integration of components is required to fulfil security functions, technical requirements should explain how to securely integrate these at the immediate architectural boundary, including interactions via interfaces to components and their configuration.</mark>

<mark>Editor's Note: Documentation of risks is not considered a means of risk mitigation. Accordingly, technical requirements must not resort to documentation as a security control, but may rather only require it to support later conformity assessment.</mark>

<mark>Editor's Note: The purpose of this standard is to make security decisions for the manufacturer to the greatest extent possible. Therefore, it is not acceptable to ask manufacturers to research and decide on a suitable approach as part of a documentation requirement instead of making a concrete recommendation.</mark>

<mark>Editor's Note: Where technical requirements rely on cryptographic primitives, protocols, and techniques, the cross vertical approach on cryptography needs to be followed.</mark>

<mark>Editor's Note: While the standard should primarily cover vertical requirements, it should also cover horizontal aspects reflecting best practices for IT systems in general. This produces a self-contained document with comprehensive guarantees.</mark>

<mark>Editor's Note: For a general interpretation of the meaning of individual essential cybersecurity requirements, consider reading corresponding clauses of prEN 40000-1-4 once released.</mark>

## 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 product shall comply with all applicable technical requirements of the present document at all times when operating in such product context.

**IMPORTANT:** Not all requirements are necessary for all products. The mapping tables at the end of each requirement shows which risk factors and use cases determine which requirements are necessary for the product.

Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product. 

**See Annex C for more information.**

<mark>Editor's Note: Each technical requirement should contain an applicability subclause as short as it might be. Example of the content of such an applicability subclause: "unconditionally applicable", "applicable to UC-1 and UC-3", "applicable if the product presents capability X," "applicable to products of type X (subcategory of product category)". Applicability subclauses may have compound criteria.</mark> 

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

<mark>Editor's Note: The applicability subclause should NOT contain generic statements, such as "Applicability based on the manufacturer's risk assessment". The legacy nature of products is also not a valid condition to exempt a product from a technical requirement. Applicability should be based on use cases and/or specific capabilities.</mark>

<mark>Editor's Note: If there is a matrix mapping the use cases to the technical requirements of the standard, it should be inserted in this clause. Alternatively, there can be such a matrix/mapping in each subclause below.</mark>

### 5.2.1 General (### 5.1.1 SSD Overview)

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (1). Products shall be designed and developed in a manner that mitigates risk appropriate to the purpose for which the product will be used.

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

This clause is a list of cybersecurity requirements necessary to satisfy essential cybersecurity requirements as described in Annex I Part I of the EU Cyber Resilience Act. Each cybersecurity requirement can be satisfied by one or more potential mitigations. A control may or may not be required to mitigate risks of an individual use case. **NOT ALL MITIGATIONS ARE NECESSARY FOR ALL USE CASES.** See clause 5.3 for the mappings of security profiles to mitigations and Annex C for additional information.

#### 5.2.2.1 Requirement (### 5.2.1 KEV Overview)

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (a). The product shall be free of known vulnerabilities when it is placed on the market.

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

<mark>Editor's Note: This is also a requirement on the product. Thus, a reference to prEN 40000-1-3 is not sufficient to fulfil it. Example of requirement: "The product shall be exempt from vulnerabilities present in xxx section of the EUVD".</mark> 

Recognizing that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known exploitable vulnerabilities both when first made available and when first used by a consumer, the product shall be able to be updated at the time of first use to address known exploitable vulnerabilities which were discovered after the product's placement on the market and before first use.

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

> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.

### 5.2.4 TR-SCUD: Secure updates (## 5.4 SU Secure updates)

#### 5.2.4.1 Requirement (### 5.4.1 SU Overview)

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c). The product shall be securely updatable.

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

#### 5.2.4.2 MI-SUDC: Documentation of secure update (### 5.4.N SU)

* **\[REQ-SU-v6czw-0]** The key or keys authorized to sign Repository Metadata shall be keys restricted to this specific purpose.

* **\[REQ-SU-v6czw-1]** Update clients shall verify that the key or keys that sign the Repository Metadata are keys authorized for that specific purpose.

**Guidance:** Signing software updates is a very sensitive role. As such, the software update system needs effective controls to ensure that the key used to sign repository metadata is the key intended for that role. This can be accomplished via specifying roles in root metadata as defined in Uptane/TUF (IEEE-ISTO 6100.1.00) [\[i.9\]](#_ref_i.9), or can be specified using a PKI system, for example via extended role attributes in an X.509 [\[i.10\]](#_ref_i.10) software signing certificate.

**Guidance:** Signing software updates is a very sensitive role. As such, the software update system needs effective controls to ensure that the key used to sign repository metadata is the key intended for that role. This can be accomplished via specifying roles in root metadata as defined in Uptane/TUF (IEEE-ISTO 6100.1.00) [\[i.10\]](#_ref_i.10), or can be specified using a PKI system, for example via extended role attributes in an X.509 [\[i.11\]](#_ref_i.11) software signing certificate.

[//]: # (### 6.4.N SU)

#### 5.2.10.1 Requirement

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i). The VPN shall by default not establish routes between different client endpoints.

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

#### 5.2.10.2 MI-EISO: No route between different endpoints (### 5.10.N IM)

#### 5.2.19.1 Requirement (### 5.9.1 AP Overview)

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h). The product shall protect the availability of essential functions.

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

#### 5.2.19.2 MI-FDRP: Fast packet drop (### 5.9.N AP)

> NOTE: Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets.

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

## 5.3 Risk mitigation sets

### 5.3.1 Overview

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

<mark>Editor's Note: The assessment clause should not contain "hidden" requirements. This means that all required specificities regarding the technical requirements should appear in clause 5. Clause 6 is only about verifying that the product complies with such technical requirements.</mark>

<mark>Editor's Note: The assessment clause should not mandate a "self-assessment" or "third party conformity assessment". The assessment clause should be without prejudice to specific conformity assessment procedures as detailed in Annex VIII of the CRA.</mark>

<mark>Editor's Note: Elements of the assessment clause should map one-to-one to elements of the technical requirements clause, ensuring there is a direct correspondence both ways. This means there shall be no summary assessment criteria.</mark>

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

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.

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.

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

- **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 th 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 analyzers, static code analyzers, cryptographic test suites).

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

<mark>Editor's Note: Precisely reference individual tools or include an unambiguous characterization 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. Assessment activities may include, as applicable:

- **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).

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

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

- **Assignment of Verdict:** Defines the pass/fail criteria.

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

  - **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).

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

- **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._

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

_Proposed structure for indexing the assessment criteria:_

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

## 6.2 No known exploitable vulnerabilities

Proposed ESR code: KEV

## 6.3 Secure by design

Proposed ESR code SBD

## 6.4 Secure Updates

Proposed ESR code: SU

## 6.5 Authentication and Access Control

Proposed ESR code: AAC

## 6.6 Confidentiality

Proposed ESR code: CON

In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography assessment criteria.

## 6.7 Integrity

Proposed ESR code: INT

## 6.8 Data Minimization

Proposed ESR code: DM

## 6.9 Availability Protection

## 6.2 Appropriate level of cybersecurity

Proposed ESR code: AP

## 6.3 No known exploitable vulnerabilities

## 6.10 Impact Minimization

## 6.4 Secure by default configuration

Proposed ESR code: IM

## 6.5 Security updates

## 6.11 Minimization of Attack Surfaces

## 6.6 Authentication and access control

Proposed ESR code: MAS

## 6.7 Confidentiality protection

## 6.12 Exploitation Mitigation Mechanisms

## 6.8 Integrity protection

Proposed ESR code: EMM

## 6.9 Data minimization

## 6.13 Logging and Monitoring

# 6.10 Availability protection

Proposed ESR code: LOG

# 6.11 Non-interference

## 6.14 Data Removal and Transparency

# 6.12 Attack surface minimization

Proposed ESR code: DRT

# 6.13 Exploit mitigation

## 6.15 Vulnerability Handling

# 6.14 Monitoring

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

# 6.15 Factory reset and data portability