@@ -817,28 +817,62 @@ Indirect users of network interfaces include:
* User administration skill: High
* Operational environment: High sensitivity device connected to public network in access-controlled area
# 5 Cybersecurity requirement specifications
# 5 Technical requirements for the Products
## 5.1 Notes on the structure of cybersecurity 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>
A Cybersecurity requirement is a security or other functional element that a product must have to comply with this standard. An ideal cybersecurity requirement is technical, meaning it is objectively testable on an instance of the product. If a cybersecurity requirement cannot be tested on the product itself, it is a cybersecurity documentation requirement, where the manufacturer documents the steps they have taken to implement it. Any documentation required to meet the cybersecurity requiremetns of this standard must be detailed (including materials such as configuration files or written policies used by employees), and will ideally be sufficent replicate the manufacturer's tests. Limited documentation, such as that indicating only that a test was completed, do not meet the cybersecurity requirements of this standard.
<mark>Editor’s Note: Requirements should be written with “shall” statements.</mark>
Each technical requirement provided in clause 5.2 consists of various mitigations, security features or elements that a product shall include. Mitigations are how a technical cybersecurity requirement can be satisfied. Mitigations provided in this standard are tailored to the use case of the product and take into account the user’s sophistication and the operational environment. However, mitigations may vary considerably based on a product's use case and the risk factors associated with it. The list of appropriate mitigations for a use case is captured a security profile listing all necessary technical requirements. Secuirty profiles are listed below in clause 5.3.
<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>
While risks may not be transffered to the user, some risks may be treated partially or fully by other, connected elements of the system. When that is the case, mitigations that allow a risk to be treated externally are included as an option to fulfill a technical cybersecurity requirement, depending on the use case and risk factors.
<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>
**IMPORTANT:** Not all cyberseecurity requirements or mitigations are necessary for all products. The mapping tables at the end of each cybersecurity requirement shows which risk factors and use cases determine which cybersecurity requirements are necessary for the product.
<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 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>
## 5.1 Introduction
### 5.1.1 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 a product context.
**See Annexes C and D for more information.**
Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product.
The term "cybersecurity-relevant" is used to allow the assessor to exclude some elements of the product from assessment if they are not relevant to the essential cybersecurity requirement being assessed. The exclusion must be documented with a clear reason. It is never required to identify which parts of the product are cybersecurity-relevant as long as all parts that are not excluded are assessed.
### 5.2.1 General
<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>
This clause is a list of technical cybersecurity requirements necessary to satisfy the CRA essential requirements. Each technical cybersecurity requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following clause will define which mitigations will be required, depending on risk factors and/or a use case.
<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>
**See Annex C for more information.**
<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 ER-NKEV: No known exploitable vulnerabilities at first use
