Remove inappropriate references to "manufacturer"

**See Annex C for more information.**

The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it can't be tested on the product itself, it is a documentation requirement, in which the manufacturer proves that it meets the requirement by collecting documentation of the steps they took to implement the requirement (such as configuration files or written policies used by employees).

The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it can't be tested on the product itself, it is a documentation requirement, in which the assessor documents the steps they took to implement the requirement (such as configuration files or written policies used by employees).

The alternative is “check-box” requirements, which only require that the vendor says that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”). These are not acceptable and should be converted into testable requirements if possible and documentation requirements otherwise.

#### 5.2.X.x Requirement

Recognizing that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known vulnerabilities both when first made available and when first used by a consumer, the manufacturer shall ensure that the product can be updated at the time of first use to address all known exploited vulnerabilities which were discovered after the product's placement on the market and before that first use.

Recognizing that there may be vulnerabilities discovered between the time that a product is placed on the market and the time of that product's first use, and that the product should be free from known vulnerabilities both when first made available and when first used by a consumer, the product shall be able to be updated at the time of first use to address all known exploited vulnerabilities which were discovered after the product's placement on the market and before that first use.

#### 5.2.X.x **MI-KEVD**: Documentation for secure update before or during first use

The product's development and release process shall include a process to document known exploitable vulnerabilities in the product and their fixes or mitigations. The documentation for this process shall be compliant with the process described in <a ref="_ref_3">[3] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling". The product shall be compliant with this requirement if it:

1. has no known exploitable vulnerabilities

1. has known exploitable vulnerabilities whose age is consistent with the manufacturer's documentation of how long vulnerabilities may go unfixed after public disclosure

1. has known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each detected vulnerability, has documentation of how the risk has been mitigated

  * Reference: TR-NKEV

The product shall be tested for all known exploitable vulnerabilities to demonstrate that each has been mitigated. The product shall be compliant with this requirement if it:

1. has no known exploitable vulnerabilities

1. has known exploitable vulnerabilities whose age is consistent with the manufacturer's documentation of how long vulnerabilities may go unfixed after public disclosure

1. has known exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each tested vulnerability, the test result shows that the vulnerability has been mitigated

  * Reference: TR-NKEV

If automatable and freely-usable vulnerability scanners are available for the product, then the product shall satisfy the following with respect to the three (or fewer, if fewer than three are avilable) most comprehensive of such scanners:

1. has no vulnerabilities discovered by scans

1. has discoverable vulnerabilities whose age is consistent with the manufacturer's documentation of how long vulnerabilities may go unfixed after public disclosure

1. has discoverable exploitable vulnerabilities whose age is consistent with the specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

1. for each detected vulnerability, has publicly available documentation explaining how the risk has been mitigated

  * Reference: TR-NKEV

  * Objective: Prevent unauthorized memory access

  * Preparation: None

  * Activities: Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached

  * Verdict: Code coverage was at least 95%, all reported memory errors are documented => PASS, otherwise FAIL

  * Evidence: Logs of code coverage tool, memory error report, any documentation of memory errors

  * Verdict: Code coverage was at least 95%, all reported memory errors are documented and justified => PASS, otherwise FAIL

  * Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors

#### 5.2.X.x MI-IMSL Implement in a memory-safe language

The manufacturer shall implement the network interface firmware and/or software in a memory-safe language. The manufacturer shall document any use of unsafe memory features to explain why they are necessary and do not present a security risk.

The product's firmware and/or software shall be implemented in a memory-safe language. Any use of unsafe memory features shall be documented to explain why they are necessary and do not present a security risk.

  * Reference: TR-SSDD, TR-MSAF

  * Objective: Prevent unauthorized memory access

#### 5.2.X.x Requirement

The manufacturer shall minimize exposed interfaces in the default configuration of the product in all operating modes, including initial configuration, during initialization, while in use, while shutting down or paused, or after reset.

The product's exposed interfaces shall be minimized in the default configuration of the product in all operating modes, including initial configuration, during initialization, while in use, while shutting down or paused, or after reset.

#### 5.2.X.x **MI-JSTY**: Document and justify exposed interfaces

SP-WD-1: KEVD, SCFS, SUDC, (SUVP or SUOE), NTFY or WDOG, LOGG, VULH

SP-WD-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SDEE-1, SDEE-4, ADEF, DPAH,  SUDC, (SUVP or SUOE), CDTX, DCTX, DJST, WDOG, JSTY, LOGG, VULH

SP-WD-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SDEE-1, SDEE-4, ADEF, DPAH,  SUDC, (SUVP or SUOE), CDTX, DCTX, DJST, WDOG, JSTY, LOGG, VULH

SP-WD-3: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDTX, DCTX, NTFY or WDOG, JSTY, LOGG, VULH

SP-WD-3: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDTX, DCTX, NTFY or WDOG, JSTY, LOGG, VULH

SP-WD-4: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDTX, DCTX, DJST, WDOG, JSTY, LOGG, VULH

SP-WD-4: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDTX, DCTX, DJST, WDOG, JSTY, LOGG, VULH

### 5.3.2 Wireless network interface risk mitigation sets

SP-WL-1: KEVD, SCFS, SSCA, IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

SP-WL-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

SP-WL-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

SP-WL-3: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

SP-WL-3: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

### 5.3.3 Virtual network interface risk mitigation sets

SP-VI-1: KEVD, SCFS, IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, IDST, DCTX, NTFY or WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, VULH

SP-VI-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or ETIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCST, DCTX, DJST, WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, SDTR, VULH

SP-VI-2: KEVD, (KEVL or SCAN), SCFS, SSCA, (FZ95 or BTIN or IMSL), IMSL or (MSAF-\*, MZRO-\*), SUDC, (SUVP or SUOE), CDST, CDTX, IDST, DCST, DCTX, DJST, WDOG, JSTY, LOGG, RSET or INST or DELE, SDRF, SDTR, VULH

# 6 Conformity Assessment

### C.2.1 List of risk factors

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The manufacturer determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

Risk factors determine which mitigation(s) satisfy each of the technical requirements in clause 5.2. The assessor of a product determines the level of each risk factor via the development of a threat model and risk profile based on the intended and foreseeable use and misuse of the operating system.

Risk factors may increase the likelihood of an incident, increase the impact of an incident, or both. As a result, different mitigation strategies may be more or less relevant to different risk factors.

### C.4.3 List of threats and risk assessments

**[TH-KEVU]:** Attacker may use known exploitable vulnerabilities in the network interface implementation to get unauthorized access to product assets.

**[TH-KEVU]:** Attacker may use known exploitable vulnerabilities in the product implementation to get unauthorized access to product assets.

| Risk factors                              | Likelihood |

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

Requirements: NKEV, SCUD, SSDD, MSAF, LMAS, LOGG, VULH

**[TH-UEVU]:** Attacker may use unknown exploitable vulnerabilities in the network interface implementation to get unauthorized access to product assets.

**[TH-UEVU]:** Attacker may use unknown exploitable vulnerabilities in the product implementation to get unauthorized access to product assets.

| Risk factors                   | Likelihood |

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

### C.6.1 General

Security profiles are an informative resource to the manufacturer. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.

Security profiles are an informative resource to the assessor. Each security profile is associated with a collection of levels of risk factors. Security profiles will be mapped to specific mitigations for each security requirements necessary to treat the risk.

### C.6.2 Mapping of security profile to risk factors

### E.4.2 Manufacturer declares intended purpose/use case

For the purposes of the CRA, the manufacture declares an intended purpose and reasonablity foreseeable use and misuse for a product. This allows the manufacturer to do a risk assessment that is specific to a particular use case.

For the purposes of the CRA, the manufacturer declares an intended purpose and reasonablity 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 requirements