The risk modeling approach followed in this document can be applied to two situations:
1. _Covered_: For Manufacturers of products with use cases that are present in the text of this document, it states the mitigations which the product shall implement and provides guidance on how to verify that the mitigations are implemented in a product. Furthermore, it describes why that unique set of mitigations is sufficient for the use case.
1. _Not Covered_: For Manufacturers of products whose use case does not precisely match use cases covered in the present document, the methodology used herein may be further used to derive the appropriate set of mitigations for a given product, and to communicate this justification in a structured way. This could inform revisions of this document and the list of use cases over time.
**Methodology**
This clause describes the methodology followed in the current text.
1. Document a comprehensive range of foreseeable use cases for products of this type.
1. For a particular use case, document the inherent and product-specific risk factors likely to affect products of that type which are not already covered by other relevant standards.
1. For that use case, document environmental risk factors likely to affect products of that type which are not already covered by other relevant standards.
1. Document a comprehensive list of threats. For each threat, create a formula to estimate the risk level using the risk factors.
1. For each threat, document appropriate mitigations which should be present to mitigate the specific risk depending on the risk level. For each mitigation, also document at least one verification methodology.
1. Create a mapping between each use case and each risk factor, assigning a proportionality score. The scoring range should start from zero, representing the inapplicability of a risk factor to a use case, and increase monotonically based on both the likelihood and severity of potential harm or impact.
1. Develop security profiles from the use cases, which are collections of risk factor levels that can be used to fully describe the risk levels of all relevant threats. There may be one use case per security profile or multiple. There should be as many security profiles as are useful to manufacturers.
1. Using the risk factors in the security profiles and the risk formulas and mitigations for all threats, derive the completed list of required mitigations for each security profile.
## D.2 Mapping of risks to cybersecurity requirements
If the Likelihood and Impact of a risk are already Low or have been reduced to Low by application of mitigations, then the risk is acceptable. Alternatively, the risk may be transferred to the user or the operational environment, given proper justification.
## D.4 Risks not treated by the cybersecurity requirements
For each risk untreated by the product itself, a corresponding mitigation has been created to explicitly permit the risk to be transferred to the user or operational environment. These are:
* MI-KEVD
* MI-KEVM
* MI-DPAH
* MI-PDDI-1
* MI-SUDC
* MI-SUOE
* MI-SUAO
* MI-DOCC
* MI-DOST
# Annex E: Explanation of the present document (informative only)
## E.1 Introduction
This is a short introduction to how standards work, how CRA vertical standards work in general, and how this standard specifically works.
## E.2 How to understand a vertical standard
### E.2.1 General
The present document is a vertical standard for the Cyber Resilience Act. This is a new kind of standard with some unusual properties. Read the rest of this clause to understand how it works.
### E.2.2 TL;DR
The manufacturer defines an intended purpose or use case for their product. This use case determines how the essential cybersecurity requirements of the CRA can be satisfied.
The vertical standard is only one way of assessing CRA conformance. Others methods are available if the product uses incompatible methods of CRA conformance.
Clauses 1 - 4 are not binding, just helpful context. Clauses 5 sets out the cybersecurity requirements necessary to conform with the CRA. Clause 6 sets out how to assess the conformance of the product with the CRA.
Each technical cybersecurity requirement can be satisfied by one or more mitigations describing the default behaviour of the product. The user may configure the product differently unless explicitly forbidden in the text of the cybersecurity requirement. Which mitigations are required depend on risk factors specific to each use case, and capabilities of the product. The tables at the end of each cybersecurity requirement show which mitigations are required.
Security profiles are groups of use cases that can be satisfied with the same mitigations. A product must fit into a security profile to use the vertical standard for CRA conformance. If a security profile includes mitigations that are sufficient to treat all of a product's cybersecurity risks, then the product may be assessed using the vertical standard.
## E.3 Standard basics
### E.3.1 Normative and informative text
Standards consist of two kinds of text: informative and normative. Informative text is just \"for your information\": it is helpful for understanding the standard but it has no legally binding meaning. Normative text describes things that matter for conforming for the standard.
This vertical standard has only two normative clauses: Clause 5 Cybersecurity requirements and Clause 6 Assessment criteria. Everything else is just to help the reader understand the normative parts of the document. That means if something in clauses 1 - 4 or the Annexes isn't exactly correct, that doesn't affect the way you can use the standard.
### E.3.2 Cybersecurity requirements describe default configuration only
The cybersecurity requirements describe the default configuration of the product. It is implied that the product can be configured to behave in a different way, unless the cybersecurity requirement explicitly states that the product may not permit such an option. For example, if a cybersecurity requirement says a debug interface must be disabled, then the product may have an option to enable the debug interface. Only if the requirement says a debug interface must be _permanently_ disabled would it be not allowed to have an option to enable it.
## E.4 CRA vertical standard specifics
### E.4.1 Vertical standards are optional
Using a CRA vertical standard to assess conformance with the CRA is optional. A product may be assessed for conformance using a variety of other options as outlined in the CRA. If the vertical standard does not fit a specific product, then the manufacturer has many other options for assessment.
However, there are two advantages to using a vertical standard: (1) it allows self-assessment of Important Class II products, (2) it provides presumption of conformity. Note that all products consistently entirely of free and open source software as defined by the CRA can always self-assess, with or without a vertical standard.
### E.4.2 Manufacturer declares intended purpose/use case
For the purposes of the CRA, the manufacturer declares an intended purpose and reasonably foreseeable use and misuse for a product. This allows the manufacturer to do a risk assessment that is specific to a particular use case.
### E.4.3 Intended purpose/use case and capabilities determines how to satisfy cybersecurity requirements
A vertical standard includes a set of cybersecurity requirements and ways to satisfy them. The ways to satisfy them are **dependent on the use case and capabilities** of a product.
### E.4.4 Each cybersecurity requirement can be satisfied by one or more mitigations
Each cybersecurity requirement is associated with a set of mitigations that reduce the cybersecurity risk of the product. Which mitigations are required to be implemented depend on the intended purpose/use case.
### E.4.5 Risk factors determine which mitigations are necessary
Each vertical standard defines a set of risk factors. The values of these risk factors are determined by the use case and/or the capabilities of the product. Which mitigations are necessary are determined by a combination of risk factors and capabilities. Each cybersecurity requirement ends with a table showing which mitigations are required, based on risk factors and capabilities.
### E.4.6 Use cases are grouped into security profiles
Security profiles are use cases grouped together by compatible mitigations. Each security profile describes a set of mitigations which can be used to satisfy the CRA essential requirements for any use case that is part of the security profile.
### E.4.7 New use cases and security profiles may be contributed
New use cases and security profiles may be developed using existing or new risk assessments, risk factors, and mitigations. It is in the manufacturer's interest to contribute the risk assessment and mitigations for their use case to the vertical standard, as they may then get the benefits of conformance via a CRA vertical standard for their product.
### E.4.8 Manufacturer may use any CRA-conformant risk assessment methodology
The risk assessment clause of a vertical standard is informative only. It exists to demonstrate that the standards writers have undertaken a risk assessment of the product. The manufacturer is explicitly permitted to use any risk assessment methodology consistent with the essential requirements in the CRA.
# Annex F (informative): Change history
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.
