Minor edits

<div align="center">

<div style="text-align: center;">

![~~ETSI Standard header image~~](media/etsi-coverpage-logo.png)

Sub-part #: Sub-part element of title<br />

Release #

Release #<br />

</div>

<br />

<br />

<div align="center">

<div style="text-align: center;">

Reference<br />

&lt;Workitem><br />

Keywords<br />

<br />

<div align="center">

<div style="text-align: center;">

**_Important notice_**

The Technical Body may propose different dates to the default ones (3, 6, 18). Technical Bodies who wish to propose different dates are advised to indicate this clearly in the approved committee draft.

| Proposed national transposition dates                          |                                 |

| -------------------------------------------------------------- | ------------------------------- |

|----------------------------------------------------------------|---------------------------------|

| Date of latest announcement of this EN (doa):                  | 3 months after ETSI publication |

| Date of latest publication of new National Standard            |                                 |

| or endorsement of this EN (dop/e):                             | 6 months after doa              |

- <a name="_ref_1">[1]</a> &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

<mark>FIXME more normative references</mark>

## 2.2 Informative references

For the purposes of the present document, the following abbreviations apply:

| Abbreviation | Description    |

| ------------ | ----------------- |

|--------------|----------------|

| OS           | Operating System  |

| IDP          | Identity Provider |

> List the essential functions of the product, including:

>

> - What it does during its intended or reasonably foreseeble use?

> - What it does during its intended or reasonably foreseeable use?

> - How its functions are configured?

> - How it keeps itself secure and functioning?

> Describe the classes of users for this product, as differentiated by sophistication in understanding and taking responsibility for security risks. More sophisticated users can be expected to follow more instructions and cope with higher levels of unmitigated risks. Suggestions:

>

> - General public

> - Children

> - Assistants to primary user

> - IT professionals

> - Systems integrators

> * General public

> * Children

> * Assistants to primary user

> * IT professionals

> * Systems integrators

## 4.9 Risk distribution among components

> - PT2 drafts, available in the [ETSI DocBox](https://docbox.etsi.org/CYBER/CYBER/CEN-CLC/JTC13/WG09)

> - ENISA's [CRA Requirements Standards Mapping](https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber%20Resilience%20Act%20Requirements%20Standards%20Mapping%20-%20final_with_identifiers_0.pdf)

> Why do we need security levels? Isn't the base operation the same, but the applicaton usage context different? Stricter security expectes more imlemented features.

<mark>FIXME define why and what levels to use</mark>

## 5.2 Use cases by security level

<mark>FIXME define use cases for all levels defined</mark>

# 6 Requirements specifications

## 6.1 Product's technical requirements specifications

# Annex A (informative): Mapping between the present document and CRA requirements

> Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements.

| CRA requirement                                 | Technical security requirements(s) |

| ----------------------------------------------- | ---------------------------------- |

|-------------------------------------------------|------------------------------------|

| No known exploitable vulnerabilities            |                                    |

| Secure design, development, production          |                                    |

| Secure by default configuration                 |                                    |

Harmonised Standard ETSI EN 304 621

| Requirement |                 |                                |                                       | Requirement Conditionality |               |

| ----------- | --------------- | ------------------------------ | ------------------------------------- | -------------------------- | ------------- |

|-------------|-----------------|--------------------------------|---------------------------------------|----------------------------|---------------|

| **No**      | **Description** | **Requirements of Regulation** | **Clause(s) of the present document** | **Use case**               | **Condition** |

| 1           |                 |                                |                                       |                            |               |

| 2           |                 |                                |                                       |                            |               |

**Requirement Conditionality:**

**U/C** Indicates whether the requirement is unconditionally applicable (U) or is conditional upon the manufacturer's claimed functionality of the equipment (C).

**Use case** Indicates whether the requirement is unconditionally applicable (U) or is conditional upon the manufacturer's claimed functionality of the equipment (C).

**Condition** Explains the conditions when the requirement is or is not applicable for a requirement which is classified "conditional".

The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.

| Date            | Version | Information about changes                 |

| --------------- | ------- | ----------------------------------------- |

|-----------------|---------|-------------------------------------------|

| &lt;Month year> | <#>     | &lt;Changes made are listed in this cell> |

|                 |         |                                           |

|                 |         |                                           |

# History

> The following table will automatically be filled in by the ETSI Secretariat.

The following table will automatically be filled in by the ETSI Secretariat.

| Document Hisotry |      |                |

| ---------------- | ---- | -------------- |

| Document History |      |                |

|------------------|------|----------------|

| Version          | Date | Milestone      |

| <Month year>     | <#>  | <Changes made> |