EN-304-617.md.backup

_See the functions in Section 4.4._

## D.2 Threats

_Based on the assets, what are the threats during:_

- _Use for intended purpose or reasonably foreseeable use_
- _When integrated into another product_

_Example threats can be found in the same documents suggested in the section on security requirements._

## D.3 Assumptions

_List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases. Some examples might include:_

- _Not being attacked by a state actor_
- _Not using sophisticated or expensive hardware snooping techniques_
- _No secret hardware backdoors in other components_

## D.4 Risk assessments of threats

_For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security levels._

_Guidance from latest PT1 draft:_

> _An analysis in terms of likelihood and magnitude of a product’s threats is required to be able to determine the product’s risks._
> _NOTE 1 This document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks._
> _NOTE 2 A qualitative estimation of the cybersecurity risks can be performed using risk matrices that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to cybersecurity risk categories._
> _NOTE 3 A quantitative estimation of the cybersecurity risks can be performed using scoring systems that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to certain values._

# Annex E (informative): Risk evaluation guidance

## E.1 Mapping of risks to requirements

_Table mapping the identified risks to requirements_

## E.2 Risks not treated by the requirements

_If any risks are not treated by the normative requirements, describe non-normative suggestions to mitigate them._

## E.3 Risk acceptance criteria

_Describe how to decide if residual risks are tolerable._

## E.4 Residual risks

_Describe how to treat any residual risks, for example by documenting them or informing the user._

# Annex K
Crypto todo

https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en 

# Annex L (informative): Relationship between the present document and the requirements of EU Regulation 2024/2847

DRAFT ANNEX L - DO NOT CONSIDER THE CONTENT

The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).
Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.
> NOTE:    The above paragraphs have to be repeated in the Foreword.

The annex shall have a table for a clear indication of correspondence between normative clauses of the standard and the legal requirements aimed to be covered.

**It should be evaluated - on the basis of the legal requirements supported and other information given in a harmonised standard - how detailed correspondence can be indicated between the normative elements of the harmonised standard and the legal requirements aimed to be covered. However, where this correspondence is expressed in too general terms, it could lead to a situation where the Commission cannot assess whether the Harmonised Standard satisfies the requirements, which it aims to cover, and subsequently publication of its references in the OJEU according to Article 10(6) of the Regulation is significantly delayed or is not possible at all.**

# Annex : Change history

| Date       | Version | Information about changes |
|------------|---------|---------------------------|
|&lt;Month year>|   <#>   | &lt;Changes made are listed in this cell> |
|            |         |                           |
|            |         |                           |
|            |         |                           |

<br />

# History

| Version      | Date         | Milestone      |
|--------------|--------------|---------------|
| <Month year> | <#>          | <Changes made>|
|              |              |               |
|              |              |               |