The technical documentation referenced in this clause is intended to describe the product design, dependencies, and implemented measures relevant to demonstrating conformity with the applicable requirements of the present document.
## 5.1 General
The following requirements shall be implemented by all products with digital elements evaluated with the present document.
-**[REQ-GEN-2]:** The product shall describe the dependencies to Operating System essential security capabilities.
-**[REQ-GEN-3]:** The products shall describe the external services and systems that are required for the product operation.
-**[REQ-GEN-4]:** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
-**[REQ-GEN-5]:** The product shall describe the core requirements and expectations for the operational environment (OE).
System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.
[4.10.1 External security functions, not in scope of the present document]:#4101-external-security-functions-not-in-scope-of-the-present-document
### 5.1.1 No known exploitable vulnerabilities
If the deliverable contains or requires an operating system the operating system is expected to be regularly updated and maintained.
@@ -574,50 +561,6 @@ DDoS mitigations:
## 6.1 General requirements assessments
### 6.1.0.2 REQ-GEN-2
**Objective:** Dependencies to OS capabilities are documented and understood.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
**Verdict:**
1. Pass if important and essential OS services and concepts are named
1. and their usage to run the application workload is clearly expressed as part of the architecture description.
1. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.1.0.3 REQ-GEN-3
**Objective:** Product dependencies to external services and systems are documented and understood.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
2. Cross-reference the documentation to the system operation.
3. Monitor the network traffic and capture all targets the systems is trying to initiate a connection with.
**Verdict:**
1. Pass if product dependencies or external systems are named and their purpose and provisions are described
2. and the services or external systems are clearly expressed as part of the architecture description
3. and the monitored network traffic targets matches the documentation.
4. Fail otherwise.
**Supporting Evidence:**
1. References to the documentation sections.
2. Listing of discovered targets and an explanation of those targets.
### 6.1.1 No known exploited vulnerabilities tests
@@ -1016,14 +1016,6 @@ While system updates are critical for the product, the installation is fully ind
# 5 Technical requirements for the Products
<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: 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>
@@ -1033,25 +1025,9 @@ NNN - Incremental and unique sequence of numbers and letters
<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 prioritisation 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>
The technical documentation referenced in this clause is intended to describe the product design, dependencies, and implemented measures relevant to demonstrating conformity with the applicable requirements of the present document.
## 5.1 Introduction - Applicability of the requirements
@@ -1059,26 +1035,39 @@ The technical requirements of the present document apply under the product conte
Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product.
When requirements are divided into low-medium-high categories, the categories are cumulative.
Medium requirement level shall implement also requirments listed in low level.
High requirement level shall implement all requirements in the defined set of requirements.
<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>
<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>
| Use-case | Requirement set | required level |
| :------- | :-------------- | -------------- |
| all | CYB_* | all |
## 5.2 Appropriate level of cybersecurity
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (1).
<mark>_Proposed ESR code: CYB_</mark>
System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.
<mark>Editor’s Note: Please refer to point 7.2 of the Commission CRA draft legal guidance for this essential requirement.</mark>
On product architecture and design:
<mark>Editor’s Note: It is not adequate to normatively reference prEN 40000-1-2 (PT1) to fulfil this requirement.</mark>
***CYB_GENERAL_1**: The product shall define whether a service is completely fulfilled by the product itself.
***CYB_GENERAL_2**: The product shall describe the external services and systems that are required for the product operation.
***CYB_GENERAL_3**: The product shall define how it is dependent on RDPS.
***CYB_GENERAL_4**: The product shall describe the dependencies to Operating System essential security capabilities.
***CYB_GENERAL_1**: The product shall define whether a service is completely fulfilled by the product itself or expected to integrated into in operative environment.
***CYB_GENERAL_2**: The product shall define where it relies on existense of external services.
***CYB_GENERAL_3**: The product shall define how it dependent on RDPS.
***CYB_RDPS_1**: Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in Annex R.
On operative environment:
***CYB_GENERAL_5**: The product shall describe the core requirements and expectations for the operational environment (OE).
***CYB_GENERAL_6**: The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
***CYB_GENERAL_7**: Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.
@@ -1261,6 +1250,50 @@ NNNNN - Incremental and unique sequence of numbers and letters - could be the sa
## 6.2 Appropriate level of cybersecurity
### 6.2. REQ-GEN-2
**Objective:** Dependencies to OS capabilities are documented and understood.<br/>
**Preparation:** None<br/>
**Activities:**
1. Study the technical documentation.
**Verdict:**
1. Pass if important and essential OS services and concepts are named
1. and their usage to run the application workload is clearly expressed as part of the architecture description.
1. Fail otherwise.
**Supporting Evidence:**
1. References to to documentation sections.
### 6.2. REQ-GEN-3
**Objective:** Product dependencies to external services and systems are documented and understood.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
**Activities:**
1. Study the technical documentation.
2. Cross-reference the documentation to the system operation.
3. Monitor the network traffic and capture all targets the systems is trying to initiate a connection with.
**Verdict:**
1. Pass if product dependencies or external systems are named and their purpose and provisions are described
2. and the services or external systems are clearly expressed as part of the architecture description
3. and the monitored network traffic targets matches the documentation.
4. Fail otherwise.
**Supporting Evidence:**
1. References to the documentation sections.
2. Listing of discovered targets and an explanation of those targets.
