Record references

The following referenced documents are necessary for the application of the present document.

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

* <a name="_ref_1">[1]</a>    CEN EN 40000-1-2 (2025): “Cybersecurity requirements for products with digital elements — General principles for cyber resilience”

* <a name="_ref_2">[2]</a>    CEN EN 40000-1-3 (##): “Cybersecurity requirements for products with digital elements – Vulnerability Handling”

* <a name="_ref_3">[3]</a>    EUCC (v2) “EUCC Guidelines Cryptography v2” https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en

[//]: # (* <a name="_ref_1">[3]</a> CEN ## (##): TK possible vocabulary document from WG9)  

[//]: # (* <a name="_ref_1">[4]</a> ETSI ## (##): TK shared vocabulary document from WG EUSR)

* <a name="_ref_3">[3]</a>    OWASP ASVS (v5.0.0): “Application Security Verification Standard”

* <a name="_ref_4">[4]</a>    OWASP MASVS (v2.1.0): “Mobile Application Security Verification Standard”

* <a name="_ref_2">[2]</a>    CEN EN 40000-1-3 (2025): “Cybersecurity requirements for products with digital elements – Vulnerability Handling”

* <a name="_ref_3">[3]</a>    EUCC (v2) “EUCC Guidelines Cryptography v2” <https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en>

* <a name="_ref_4">[4]</a>    CEN ## (##): TK possible vocabulary document from WG9  

* <a name="_ref_5">[5]</a>    ETSI ## (##): TK shared vocabulary document from WG EUSR

* <a name="_ref_6">[6]</a>    IEEE-ITSO 6100 (1.0.0): "Uptane Standard for Design and Implementation". <https://uptane.org/papers/ieee-isto-6100.1.0.0.uptane-standard.html>

* <a name="_ref_7">[7]</a>    ITU-T x.509: "Public-key and attribute certificate frameworks". <https://www.itu.int/rec/T-REC-X.509/en>

[EDRs]: https://portal.etsi.org/Services/editHelp!/Howtostart/ETSIDraftingRules.aspx

[ETSI docbox]: https://docbox.etsi.org/Reference/

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

[//]: # (* <a name="_ref_i.0">[i.0]</a>    &lt;Standard Organization acronym> &lt;document number> &#40;&lt;version number>&#41;: "&lt;Title>".)

* <a name="_ref_i.1">[i.1]</a>    Regulation (EU) 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) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)

* <a name="_ref_i.2">[i.2]</a>    Commission Implementing Regulation (EU) TK TODO on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council (Text with EEA relevance)

* <a name="_ref_i.3">[i.3]</a>    C(2025)618 – Standardisation request M/606: Commission Implementing decision of 3.2.2025 on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (CENELEC) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 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) 2019/1020and Directive (EU) 2020/1828 (Cyber Resilience Act)

* <a name="_ref_i.4">[i.4]</a>    Commission Recommendation of 6 May 2003 concerning the definition of micro, small and medium-sized enterprises (Text with EEA relevance) (notified under document number C(2003) 1422)

* <a name="_ref_i.5">[i.5]</a>    Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity Act)

* <a name="_ref_i.1">[i.1]</a>    Regulation (EU) 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) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) <https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng>

* <a name="_ref_i.2">[i.2]</a>    Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council <https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj>

* <a name="_ref_i.3">[i.3]</a>    C(2025)618 – Standardisation request M/606: Commission Implementing decision of 3.2.2025 on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (CENELEC) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 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) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) <https://ec.europa.eu/transparency/documents-register/detail?ref=C(2025)618&lang=en>

* <a name="_ref_i.4">[i.4]</a>    Commission Recommendation of 6 May 2003 concerning the definition of micro, small and medium-sized enterprises (Text with EEA relevance) (notified under document number C(2003) 1422) <https://eur-lex.europa.eu/eli/reco/2003/361/oj/eng>

* <a name="_ref_i.5">[i.5]</a>    Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 on ENISA (the European Union Agency for Cybersecurity) and on information and communications technology cybersecurity certification and repealing Regulation (EU) No 526/2013 (Cybersecurity Act) <https://eur-lex.europa.eu/eli/reg/2019/881>

* <a name="_ref_i.6">[i.6]</a>    ETSI EN 303 645 (v3.1.3 2024-09): "Cyber Security for Consumer Internet of Things: Baseline Requirements". <https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf>

* <a name="_ref_i.7">[i.7]</a>    ETSI TC 103 701 (v2.1.1 2025-05) "Cyber Security for Consumer Internet of Things: Conformance Assessment of Baseline Requirements" <https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf>

* <a name="_ref_i.8">[i.8]</a>    CEN-CENELEC 18031 series (2024): Common security requirements for radio equipment.

[References]: https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/News_from_editHelp/References_in_ETSI_deliverables.pdf

## 3.1 Terms

This clause provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645/TS 103 701 and terms and definitions provided by CEN/CLC EN 18031 series.

This clause provides terms and definitions based on CEN/CLC JTC13 WG09's work on terms and definitions, terms and definitions provided by ETSI EN 303 645 [\[i.6\]](#_ref_i.6)/TS 103 701 [\[i.7\]](#_ref_i.7) and terms and definitions provided by CEN/CLC EN 18031 [\[i.8\]](#_ref_i.8) series.

For the purposes of the present document, the terms given in [i.1], [i.4], and the following apply:

#### 5.2.2.4 MI-KEVM: Documentation of mitigation of known exploitable vulnerabilities

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_2">[2] prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling". The product shall be compliant with this requirement if it:

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 prEN 40000-1-3: "Cybersecurity requirements for products with digital elements – Vulnerability Handling" [\[2\]](#_ref_2). 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 specification of how long vulnerabilities may go unfixed after public disclosure, as described in the vulnerability handling procedure for the product

If the update system makes use of a signed metadata file as suggested in the guidance for MI-XXXX, revoking a particular update is simply a matter of removing it from the metadata file, updating the metadata file's version number, and signing the new version. The product can then download and check the metadata file from the repository.

* Reference: TR-SCUD

* Objective: Prevent rollback attacks by rejecting previously-valid packages that contain vulnerabilities

* Objective: Prevent "rollback attacks" by rejecting previously-valid packages that contain vulnerabilities

* Preparation: Create an update image that was formerly valid but has been revoked from the repository metadata

* Activities: Attempt to install the revoked update

* Verdict: Update is not installed => PASS, otherwise => FAIL

* Evidence: Revoked update image, error message, before and after comparison of any data that would have been altered if it had been installed

FIXME JON NOTES: Perhaps we can add a definition of "rollback attack" to reduce confusion here. It's not a rollback attack to if there are multiple different versions of software that are simultaneously endorsed/trusted for installation. It's only a rollback attack when the software updater on the product/device can be tricked into trusting a software package that is no longer valid, or tricked into thinking that an older software version is actually a new update.

> [!note]

> Multiple different versions of software that are _simultaneously_ endorsed/trusted for installation do not constitute a "rollback attack". This mitigation specifically applies to the scenario where the software updater on the product/device can be tricked into trusting a software package that is _no longer_ valid, or tricked into thinking that an older software version is actually a new update.

#### 5.2.4.11 MI-SURC: Signing keys have strictly scoped usage

*Guidance*

Signing software updates is a very sensitive role. As such, the software update system needs effective controls to ensure that the key used to sign repository metadata is the key intended for that role. This can be accomplished via specifying roles in root metadata as defined in Uptane/TUF (IEEE-ISTO 6100.1.00), or can be specified using a PKI system, for example via extended role attributes in an X.509 software signing certificate.

Signing software updates is a very sensitive role. As such, the software update system needs effective controls to ensure that the key used to sign repository metadata is the key intended for that role. This can be accomplished via specifying roles in root metadata as defined in Uptane/TUF (IEEE-ISTO 6100.1.00) [\[6\]](#_ref_6), or can be specified using a PKI system, for example via extended role attributes in an X.509 [\[7\]](#_ref_7) software signing certificate.

* Reference: TR-SCUD

* Objective: Ensure keys are only used for their designated roles and prevent role confusion attacks