{"packId":"en-304-626","packVersion":"0.1.0","standard":{"reference":"ETSI EN 304 626","title":"CRA; Essential cybersecurity requirements for operating systems","status":"INTERIM DRAFT (V0.0.11, 2025-12-11) — early-stage ETSI CYBER-EUSR working draft; the draft's own cover carries the caution that it is provided for information and future development work only. Subject to substantial change before publication. Not cited in the Official Journal: conformance confers NO presumption of conformity today.","sourceUrl":"https://labs.etsi.org/rep/stan4cra/en-304-626","sourceCommit":"078b416a","retrievedAt":"2026-09-02","license":"BSD-3-Clause, © 2025 ETSI. Redistributed with attribution as the license requires; the verbatim requirement and mitigation text below is reproduced from the interim draft.","licenseText":"Copyright 2025 ETSI\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n1. Redistributions of source code must retain the above copyright notice,\n   this list of conditions and the following disclaimer.\n2. Redistributions in binary form must reproduce the above copyright notice,\n   this list of conditions and the following disclaimer in the documentation\n   and/or other materials provided with the distribution.\n3. Neither the name of the copyright holder nor the names of its contributors\n   may be used to endorse or promote products derived from this software without\n   specific prior written permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.\nIN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,\nINDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,\nBUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\nDATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF\nLIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE\nOR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED\nOF THE POSSIBILITY OF SUCH DAMAGE."},"appliesTo":{"craCategory":"important-1","annexIIIItem":"Operating systems","note":"Attaches to a product whose CRA classification matched the Annex III 'Operating systems' item, or manually."},"scope":"## 1.1 General\n\nThe present document specifies security requirements and related assessment criteria regarding the compliance of Operating Systems with EU Regulation 2024/2847.\n\nFollowing harmonised standards in the design and manufacture of products may ensure that the products comply with corresponding EU rules.\n\nThe use of harmonised standards are voluntary.\n\n## 1.2 Products in scope\n\n### 1.2.1 General\n\nProducts in scope are products whose core function and intended or reasonably foreseeable use or misuse is as an operating system. Operating systems include software products with digital elements that provide an abstract interface of the underlying hardware and control the execution of software, and that may provide services such as computing resource management and configuration, scheduling, input-output control, managing data, and providing an interface through which applications interact with system resources and peripherals. The underlying hardware may be virtualized to some degree, as when an operating system is running on a hypervisor.\n\nThis category includes but is not limited to:\n\n* General purpose operating systems\n  * Personal computing operating systems\n  * Mobile operating systems\n  * Server operating systems\n* Special purpose operating systems\n  * Real-time operating systems\n  * Embedded operating systems\n  * Single-purpose operating systems\n\nMany products contain multiple operating systems which can affect the security functions of other operating system(s) in the product. For example, a Baseboard Management Controllers (BMC) contains an operating system that can manage most or all of the hardware managed by the main system operating system. Radiofrequency transmission devices often have an embedded real-time operating system and the ability to read or write to system memory or trigger interrupts.\n\nSome of the operating systems may not always be readily available as separate products and are included as components of another product. Where there may be other specifications that target that product category, it may be more relevant to review the operating system as part of that larger system rather than independently via this standard.\n\n### 1.2.2 Components of operating systems that are in scope\n\nThe scope is of this document is limited to the security-relevant parts of the operating system, including components that provide or are capable of modifying or controlling essential security functions of the operating system.\n\nThe following non-exhaustive list of types of components are common to many operating systems and, when present, are considered security-relevant:\n\n- **Kernel:** The central component responsible for managing hardware resources and enforcing access controls.\n- **Device Drivers:** Software components supplied with the operating system that interact directly with hardware devices.\n- **Security Libraries:** Libraries used to provide critical security services, such as encryption, authentication, and authorization.\n- **Authentication Services:** Core authentication mechanisms required for operating system functionality.\n- **Privileged Processes:** Operating system processes running with elevated privileges or access to sensitive resources.\n- **Software Update Mechanisms:** Systems responsible for installing and updating software components supplied with the operating system.\n- **Logging and Monitoring:** Functions performed by the operating system that record security-relevant events or monitor system behavior.\n- **Configuration Management:** Management of the configuration of security-relevant  operating system settings, including provisioning of secure-by-default configuration as appropriate to the product context.\n\nOther components of operating systems often contribute to the essential security of a product and should be given equal consideration, as appropriate for each product's context.\n\n## 1.3 Products not in scope\n\nThe present document does not apply to products that contain an operating system or are part of an operating system if the core purpose of the product is not that of an operating system. However, it may be useful as one part of the process of demonstrating compliance for a product containing or interacting with an operating system.\n\nThe present document does not cover functions of the operating system that are not security-relevant.\n\nThe present document does not cover other product categories defined in EU Regulation 2024/2847, such as hypervisors, container runtime systems, or boot managers, even where such products provide security-relevant functionality which overlaps that of an operating system.","applicabilityIntro":"**Editor's Note:** The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In Article 13 Rec. 22, MSA's are granted the right to request \"all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I.\" The objective of these requirements is to provide manufacturers with sufficient guidance to consistently satisfy such requests from the market authorities.\n\n### 5.1.1 Necessity of Requirements\n\nNot all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\n\n### 5.1.2 Types of Technical Requirements\n\n**Testable Requirements:** The essential quality of technical requirements is their capability to be verified by testing an implementation of the product. This verification ensures that the requirement can be assessed in an objective manner. If such verification is not practicable, the requirement is instead classified as a documentation requirement.\n\n**Documentation Requirements:** For documentation requirements, the manufacturer shall provide supporting documentation, including but not limited to configuration files and documented organizational policies to ensure that compliance with the standard can be demonstrated even when direct product testing is not feasible.\n\n**NOTE:** Simple process requirements (e.g., a statement that something has been done, without supporting evidence) are not acceptable and should be converted into technical requirements whenever possible and documentation requirements otherwise.\n\n### 5.1.3 Assumptions Regarding Requirements\n\n#### 5.1.3.1 Testability\n\nManufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.\n\n#### 5.1.3.2 Source Code\n\nThe market authorities may request source code access as part of a verification process, if necessary.\n\n#### 5.1.3.3 Mitigations\n\nMitigations are the technical means by which a technical requirement is satisfied. Mitigations should be tailored to the use case and take into account the foreseeable and expected skill level of the product's users, appropriate for the expected operational environment, and proportional to the foreseeable risk.\n\n### 5.1.3.4 Risk Transferral\n\nSome risks may be transferred partially or fully to other components of the final product, or to the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.\n\nThis section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on risk factors and/or a use case.\n\n**NOT ALL MITIGATIONS ARE NECESSARY FOR ALL USE CASES.** See Section 5.3 for the mappings of security profiles to mitigations and Annex C for additional information.","useCases":[{"id":"UC-LR","title":"Operating system for learning and research","description":"* is not used for any purpose beyond learning and research\n  * does not store any sensitive or useful data\n  * security is provided entirely by the environment\n  * is highly modified by the user"},{"id":"UC-IoT-1","title":"Non-internet-connected device such as a bluetooth speaker","description":"* does not store any user-specific data\n  * has no means to connect directly to a public network\n  * not intended to support hardware, software, or operating system changes"},{"id":"UC-IoT-2","title":"Internet-enabled power switch","description":"* connects to a central service, operated by the device manufacturer, for remote data processing\n  * stores account information to authenticate to WiFi and to cloud service provider\n  * has a minimalistic interface, such as a single button for pairing and a reset button\n  * does not have accessible I/O ports"},{"id":"UC-IoT-3","title":"Internet-connected \"smart home\" device","description":"* e.g. a thermostat, fridge, or alarm system\n  * connects to a central service, operated by the device manufacturer, for remote data process\n  * stores account information to authenticate to WiFi and to cloud service provider\n  * does not support arbitrary file storage or end-user operating system configuration changes\n  * does not have accessible I/O ports\n  * may display personalized information, such as location-specific weather forecast\n  * serviced by trained professionals who do not modify software or hardware outside of manufacturer specifications"},{"id":"UC-RO-1","title":"Consumer-grade home wireless router","description":"* stores account information for authentication with ISP\n  * not intended for end-user hardware or software modification\n  * is exposed to the open internet"},{"id":"UC-OT-1","title":"Business-grade remote door locking system","description":"* does not store any user data\n  * not intended for hardware or software modification\n  * is not exposed to the open internet, and is only connected to trusted networks\n  * only serviced by professionals\n  * does not have accessible I/O ports\n  * hardware likely contains tamper-evident signals which operating system can rely on"},{"id":"UC-MOB-1","title":"Personal mobile device","description":"* stores highly sensitive personal information\n  * large number of sensors allow mass collection of sensitive personal data\n  * size and cost make it a common target of theft\n  * device usage is not limited to trusted locations and loss is foreseeable\n  * hardware and operating system configuration not intended for modification by users\n  * end-users frequently install software of uncertain provenance\n  * device frequently connects to untrusted networks\n  * device frequently collects user's location at all times\n  * device is often always on and always connected"},{"id":"UC-WE-1","title":"Wearable health tracker","description":"* e.g. a smart watch or step tracker\n  * stores information about a single user only\n  * stored information may be highly sensitive, and is likely to be strictly structured (not arbitrary files)\n  * does not have accessible I/O ports and is not user-modifiable\n  * connects to a central service, operated by the device manufacturer, for remote data processing\n  * connections are proxied by a trusted device, such as a mobile phone\n  * is not exposed to a public network"},{"id":"UC-PC-1","title":"Personal computer in a fixed and generally safe location","description":"* hardware, software and operating system may be configured and modified by the end-user\n  * the user may not be either highly skilled or an authorized representative of the manufacturer\n  * foreseeably connects to a public network and to low-trust local networks, but is not reachable from the open internet\n  * stores personal information and arbitrary files"},{"id":"UC-PC-2","title":"Enterprise workstation in a fixed and generally safe location","description":"* installed in an access-controlled workspace\n  * serviced by trained professionals who may modify both software and hardware\n  * connected to a public network with external mitigations, such as enterprise-grade firewalls\n  * connects to trusted local networks\n  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage\n  * used for web browsing\n  * stores business data, personal information and arbitrary files"},{"id":"UC-LA-1","title":"Personal laptop","description":"* hardware, software and operating system may be configured and modified by the end-user\n  * device is a foreseeable target of theft and tampering by untrusted 3rd parties\n  * stores personal information and arbitrary files\n  * unrestricted connection to a public network\n  * is frequently connected to untrusted networks\n  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage"},{"id":"UC-LA-2","title":"Enterprise laptop","description":"* hardware, software and operating system may be configured and modified by the end-user\n  * serviced by trained professionals who may modify both software and hardware\n  * device is a foreseeable target of theft and tampering by untrusted 3rd parties\n  * stores business data, personal information and arbitrary files\n  * unrestricted connection to a public network\n  * is frequently connected to untrusted networks\n  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage"},{"id":"UC-PS-1","title":"Personal server","description":"* one or a small number of trusted users\n   * installed in a fixed location at home or in a cohosting facility\n   * connected to a public network with a firewall\n   * connects to trusted local network\n   * limited access permitted from a public network for specific services\n   * semi-professional semi-automated management by one or a few people\n   * always stationary, access to hardware interfaces unlikely"},{"id":"UC-SE-1","title":"Enterprise server in a datacenter with no user accounts","description":"* installed in a monitored and secured facility\n  * serviced by trained professionals who may modify both software and hardware\n  * connected to a public network with external mitigations, such as enterprise-grade firewalls\n  * connects to trusted local networks\n  * hardware likely contains tamper-evident indicators and secure elements for cryptographic storage"},{"id":"UC-SE-2","title":"Enterprise server in a datacenter with only trusted user accounts","description":"* Same as UC-SE-2 but with trusted users"},{"id":"UC-SE-3","title":"Enterprise server in a datacenter hosting many untrusted user accounts","description":"* Same as UC-SE-2 but with untrusted users"}],"craMap":[{"craRef":"No known exploitable vulnerabilities","clauses":"NKEV"},{"craRef":"Secure design, development, production","clauses":"SSDD, LMII"},{"craRef":"Secure by default configuration","clauses":"SDEF"},{"craRef":"Secure updates","clauses":"SCUD"},{"craRef":"Authentication and access control mechanisms","clauses":"AUTH*"},{"craRef":"Confidentiality protection","clauses":"MISO, LMII, CDST, CDTX, CRYP*"},{"craRef":"Integrity protection for data and configuration","clauses":"MISO, IDST, IDTX"},{"craRef":"Data minimization","clauses":"DMIN"},{"craRef":"Availability protection","clauses":"AVAI, LMII"},{"craRef":"Minimize impact on other devices or services","clauses":"MINI, SDEF, AVAI, SSDD, LMII"},{"craRef":"Limit attack surface","clauses":"MISO, LMAS, SSDD, LMII"},{"craRef":"Exploit mitigation by limiting incident impact","clauses":"MISO, LMII, AVAI, SSDD"},{"craRef":"Logging and monitoring mechanisms","clauses":"LOGG"},{"craRef":"Secure deletion and data transfer","clauses":"SCDL, SDTR"},{"craRef":"Vulnerability handling","clauses":"VULH"}],"topics":[{"clause":"5.2.2","title":"TR-NKEV: No known exploitable vulnerabilities at first use","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-NKEV","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 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.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-KEVD","title":"Documentation for secure update before or during first use","text":"The product shall be accompanied by documentation describing how the product may be securely updated, including how to update the product prior to, or as part of, first use.\n\n  * Applicability: Product expected use is long enough to require updates\n  * Reference: TR-NKEV\n  * Objective: Prevent exploitation of known exploited vulnerabilities at first use\n  * Preparation: Examine public or private vulnerability information sources and select a recently fixed vulnerability (preferably the most recently fixed)\n  * Activities: On a new product, carry out the initial secure update, scan the product to see if a recently fixed vulnerability has been fixed on the product, and examine the documentation for the required info\n  * Verdict: The secure update completes successfully, the most recently fixed vulnerability is fixed, and the documentation includes all the required information => PASS, otherwise FAIL\n  * Evidence: Documentation of vulnerability handling, documentation of how to securely update the product, the report for the selected vulnerability, description of how to scan for the vulnerability, log of vulnerability scan results"},{"id":"MI-KEVA","title":"Automatic secure update before or during first use","text":"The product shall implement automatic secure update by default before or during first use.\n\n  * Applicability: Product expected use is long enough to require updates\n  * Reference: TR-NKEV\n  * Objective: Prevent exploitation of known exploited vulnerabilities at first use\n  * Preparation: Examine public or private vulnerability information sources and select a recently fixed vulnerability (preferably the most recently fixed)\n  * Activities: Follow the instructions to install and use the product for the first time, scan the product to see if a recently fixed vulnerability has been fixed on the product, and examine the documentation for the required info\n  * Verdict: The secure update completes successfully, the most recently fixed vulnerability is fixed, and the documentation includes all the required information => PASS, otherwise FAIL\n  * Evidence: Documentation of vulnerability handling, documentation of how to securely update the product, the report for the selected vulnerability, description of how to scan for the vulnerability, log of vulnerability scan results"},{"id":"MI-KEVM","title":"Documentation of mitigation of known exploitable vulnerabilities","text":"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 [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\". The product shall be compliant with this requirement if it:\n\n1. has no known exploitable vulnerabilities\n1. 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\n1. for each detected vulnerability, has documentation of how the risk has been mitigated\n\n  * Reference: TR-NKEV\n  * Objective: Prevent exploitation of known exploited vulnerabilities at first use\n  * Preparation: Compile a list of known exploitable vulnerabilities in the product and its components\n  * Activities: Compare the generated list of known exploitable vulnerabilities with the documentation of the known exploitable vulnerabilities that have been fixed or mitigated in the product\n  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or documentation requirement => PASS, otherwise FAIL\n  * Evidence: Documented vulnerability handling policy, list of vulnerabilities, documentation of mitigations or age of vulnerability, correlation of list of vulnerabilities with documentation of mitigations or age of vulnerability"},{"id":"MI-KEVT","title":"Testing for known exploitable vulnerabilities","text":"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:\n\n1. has no known exploitable vulnerabilities\n1. 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\n1. for each tested vulnerability, the test result shows that the vulnerability has been mitigated\n\n  * Reference: TR-NKEV\n  * Objective: Prevent exploitation of known exploited vulnerabilities at first use\n  * Preparation: Compile a list of known exploitable vulnerabilities in the product and its components, compile a list of known exploitable vulnerabilities that will be tested, collect tests for each one\n  * Activities: On a new product, carry out a secure update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities\n  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or mitigation requirement => PASS, otherwise FAIL\n  * Evidence: Documented vulnerability handling policy, list of vulnerabilities, test results for each vulnerability or documentation of age of vulnerability, correlation of list of vulnerabilities with test results or documentation of age of vulnerability"},{"id":"MI-SCAN","title":"No easily scannable known exploitable vulnerabilities","text":"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 available) most comprehensive of such scanners:\n\n1. has no vulnerabilities discovered by scans\n1. 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\n1. for each detected vulnerability, has publicly available documentation explaining how the risk has been mitigated\n\n  * Reference: TR-NKEV\n  * Objective: Prevent exploitation of known vulnerabilities at first use\n  * Preparation: Select a set of tools meeting the requirements\n  * Activities: On a new product, carry out a secure update, run the tools on the product, and examine the documentation for any reported vulnerabilities\n  * Verdict: No vulnerabilities found, or all reported vulnerabilities satisfy either the age or documentation requirement => PASS, otherwise FAIL\n  * Evidence: Documented vulnerability handling policy, list of vulnerability scanners selected, reports from each scanner, correlation of reports of discovered vulnerabilities with documentation of mitigations"}]}]},{"clause":"5.2.3","title":"TR-SSDD: Secure design and development","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-SSDD","requirement":"The product shall be designed and developed in a secure manner.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-SSCA","title":"Static source code analysis for memory errors","text":"All security-relevant parts of the product shall be checked for memory errors using a source code analysis tool that detects code that may produce common memory errors, such as:\n\n* buffer overflow\n* out-of-bounds\n* use after free\n* double free\n* use of uninitialized variables\n* dereference of invalid pointer\n\nThe sufficiency of the source code analysis tool and the selected manner of running it shall be documented.\n\nAll warnings, annotations, or other method of suppressing warnings from the analysis tool shall be documented with a rationale for why it does not constitute an unacceptable risk.\n\n  * Reference: TR-SSDD\n  * Objective: Prevent unauthorized memory access\n  * Preparation: None\n  * Activities: Review the documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings\n  * Verdict: Sufficiency documentation is acceptable, the method of running the tool is consistent with rationale, the output of source code analysis tool is consistent with the source code, all warnings or suppression of warnings have convincing documentation for why they are an acceptable risk => PASS, otherwise FAIL\n  * Evidence: The documentation on why the source code analysis tool is sufficient, how it is run, the source code for the product, the output of the source code analysis tool, and the documentation for any warnings or suppression of warnings"},{"id":"MI-FZ95","title":"Runtime code coverage checking with memory access error detection","text":"The product shall be checked for memory errors by running a tool that exercises the functions of the product in an environment that permits measuring code coverage and detecting memory access errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.\n\n  * Reference: TR-SSDD\n  * Objective: Prevent unauthorized memory access\n  * Preparation: None\n  * Activities: Run the tool while measuring code coverage and monitoring for memory access errors until 95% code coverage has been reached\n  * Verdict: Code coverage was at least 95%, all reported memory errors are documented and justified => PASS, otherwise FAIL\n  * Evidence: Logs of code coverage tool, memory error report, documentation of any memory errors"},{"id":"MI-IMSL","title":"Implement in a memory-safe language","text":"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.\n\n  * Reference: TR-SSDD, TR-MSAF\n  * Objective: Prevent unauthorized memory access\n  * Preparation: None\n  * Activities: Review source code to determine its language and what exceptions to memory safety exist\n  * Verdict: Source code is in a memory-safe language and the documentation of all uses of unsafe memory features convincingly demonstrates that each one of them does not present a security risk => PASS, otherwise FAIL\n  * Evidence: Source code, documentation of unsafe memory features"},{"id":"MI-BTIN","title":"Boundary testing of inputs that may cause memory errors","text":"The input fields of the product that may produce memory errors in the firmware or device driver shall be identified. The product shall be boundary tested for all such inputs while monitoring for memory errors. All memory errors detected shall be documented with a rationale for why it does not constitute an unacceptable risk.\n\n  * Reference: TR-SSDD, TR-MSAF\n  * Objective: Prevent unauthorized memory access\n  * Preparation: Identify input fields in the product that may produce memory errors\n  * Activities: Run a tool that tests input values that test the boundaries of the input values (minimum valid, maximum valid, minimum possible, maximum possible, off-by-one, etc.) while monitoring for memory errors\n  * Verdict: All boundary values tested and all memory errors detected are documented and justified => PASS, otherwise FAIL\n  * Evidence: Logs of boundary testing tool, memory error report, documentation of any memory errors"},{"id":"MI-SCFS","title":"Secure compilation flags","text":"All security-relevant firmware and software shall be compiled with secure compilation flags and options appropriate to the target platform and language. All compilation flags used shall be documented as to their rationale, along with any exceptions or limitations. Any exceptions to the flags or warnings shall be documented as to why they do not create an unacceptable risk.\n\n  * Applicability: Product implemented in a compiled language\n  * Reference: TR-SDDV\n  * Objective: Secure design and development\n  * Preparation: Document which flags should be used\n  * Activities: Review compilation flags, warnings, and documentation for exceptions\n  * Verdict: Documentation of flags exists, all warnings and exceptions are documented\n  * Evidence: Documentation of flags, build system files, documentation of warnings and exceptions"}]}]},{"clause":"5.2.4","title":"TR-MISO: Prevent local unauthorized access of memory-addressable security-relevant data","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-MISO","requirement":"The product shall protect memory addresses from unauthorized access by executables under the product's control, including the product itself. This includes system memory, storage addressable via memory mapping, memory for I/O devices, and anything else accessible via the memory-related instructions in the platform.\n\nThe product does not need to protect against unauthorized access by elements of the platform it is running on (e.g. CPU microcode, devices on the system bus, other operating systems in the device, a hypervisor). Future iterations of the standard may add this requirement for appropriate use cases.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-MMAC","title":"Memory access control","text":"The product shall implement mandatory hardware-enforced access control to memory to prevent unauthorized access of memory.\n\n  * Applicability: Has user accounts\n  * Reference: TR-MISO\n  * Objective: Prevent unauthorized memory access\n  * Preparation: List the methods of accessing memory and the types of access control to memory\n  * Activities: For each method of accessing memory and each type of access control to memory, attempt to use the method of accessing memory to gain access to memory that the executable is not authorized to access due to the access control\n  * Verdict: All memory accesses fail => PASS, otherwise FAIL\n  * Evidence: List of methods of accessing memory and types of access control, output of tests"},{"id":"MI-CCON","title":"Prevent creation of more than one user account","text":"The product shall prevent the creation of a user account if one already exists.\n\n  * Applicability: Has user accounts\n  * Reference: TR-MISO\n  * Objective: Prevent unauthorized access of memory\n  * Preparation: List all user accounts and verify there is exactly one\n  * Activities: Attempt to create a second user account, then list user accounts again\n  * Verdict: Creation of second user account fails and list of user accounts shows one account and is identical before and after test => PASS, otherwise FAIL\n  * Evidence: List of user accounts before and after test, output of test"},{"id":"MI-UCON","title":"Prevent concurrent user account usage","text":"The product shall prevent a user account from logging in if another user account is already logged in.\n\n  * Applicability: Has user accounts\n  * Reference: TR-MISO\n  * Objective: Prevent unauthorized access of memory\n  * Preparation: Create two accounts, log in to one account, list all logged in user accounts and verify there is exactly one, list all methods of logging in to a user account\n  * Activities: For each method of logging in to a user account, attempt to login as a second user account, then list logged in user accounts again\n  * Verdict: Login of second user account fails or is not possible, and list of user accounts logged in shows one account and is identical before and after test => PASS, otherwise FAIL\n  * Evidence: List of logged in user accounts before and after test, output of each test or evidence proving that logging in as a second user is impossible"},{"id":"MI-PMSC","title":"Prevent memory leaks through microarchitectural side channels in provided executables","text":"The product shall implement mechanisms to prevent the executables it provides from leaking memory data to unauthorized users through known exploitable microarchitectural side channels (MASCs), such as via the observing the time of cache access for various operations including:\n\n* speculative execution/loads/stores\n* branch prediction\n* out-of-order execution\n* shared multithreading resources\n* address translation\n* memory access patterns\n* prefetching\n\nTest:\n\n  * Reference: TR-MISO\n  * Objective: Prevent unauthorized reads of memory\n  * Preparation: List known MASC leaks on supported platform\n  * Activities: For each type of MASC leak, run a test using the best known techniques to exploit the MASC on a system-provided executable\n  * Verdict: All tests fail to extract data that they do not have authorization to read => PASS, otherwise FAIL\n  * Evidence: Output of each test"},{"id":"MI-TRMD","title":"Transfer risk of microarchitectural side channel data leaks to user","text":"The documentation provided to the user shall document the risk of microarchitectural side channel data leaks and give appropriate guidance to the user on how they may mitigate the risk.\n\n  * Applicability: (for requirements that depend on a feature)\n  * Reference: TR-MISO\n  * Objective: Prevent unauthorized reads of memory\n  * Preparation: None\n  * Activities: Read documentation provided with the product\n  * Verdict: Documentation sufficiently describes the risks and mitigations => PASS, otherwise FAIL\n  * Evidence: Documentation provided with the product"}]}]},{"clause":"5.2.5","title":"TR-MSAF: Mitigate memory safety errors","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-MSAF","requirement":"The product shall appropriately mitigate risks due to memory safety errors.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":{"objective":"","preparation":"None","activities":"","verdict":"each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL","evidence":"error messages, log message, or the product reboots or halts","guidance":"Most memory safety mitigations have the same Verdict and Evidence:\n\nFor each mitigation grouped under requirement TR-MSAF, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply."},"mitigations":[{"id":"MI-MSAF-1","title":"Stack exhaustion detection","text":"Both kernel and userspace threads shall reject writes beyond the end of the stack.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from writing beyond end of stack\n* Activities: For each of kernel and userspace, write beyond the end of the stack\n\nGuidance: Two methods of exhausting stack memory include allocating a very large object on the stack, and performing an unbounded recursive function call."},{"id":"MI-MSAF-2","title":"Stack linear buffer overflow detection","text":"Both kernel and userspace threads shall reject stack buffer writes that go beyond the end of the stack frame.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from writing beyond end of stack\n* Activities: For each of kernel and userspace, write beyond the end of the stack frame"},{"id":"MI-MSAF-3","title":"Array bounds checking","text":"Both kernel and userspace threads shall reject writes to fixed-size arrays that are beyond the end of the array.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from writing beyond the end of a fixed-size array\n* Activities: For each of kernel and userspace, write beyond the end of a fixed-size array"},{"id":"MI-MSAF-4","title":"Heap linear buffer overflow detection","text":"Both kernel and userspace threads shall reject writes beyond the bounds of allocated heap memory.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from writing beyond the end of heap memory\n* Activities: For each of kernel and userspace, for each type of heap memory, allocate a fixed size from each class of heap memory, write beyond it"},{"id":"MI-MSAF-5","title":"Heap use-after-free access prevention","text":"Both kernel and userspace threads shall reject use of allocated memory that has been freed.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from using memory that was allocated then freed\n* Activities: For each of kernel and userspace, allocate from heap memory, free it, then try to read it, repeat but with a write"},{"id":"MI-MSAF-6","title":"Heap free checking","text":"Both kernel and userspace threads shall reject freeing of memory that was allocated and previously freed.\n\n* Reference: TR-MSAF\n* Objective: Prevent thread from freeing memory that is already free\n* Activities: For each of kernel and userspace, allocate from heap memory, free it, then free again"}]}]},{"clause":"5.2.6","title":"TR-LMII: Limit incident impact","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-LMII","requirement":"The product shall implement appropriate mitigations to limit incident impact.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":{"objective":"","preparation":"None","activities":"","verdict":"each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL","evidence":"error messages, log message, or the product reboots or halts","guidance":"Most memory safety mitigations have the same Verdict and Evidence:\n\nFor each mitigation grouped under requirement TR-LMII, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply."},"mitigations":[{"id":"MI-MZRO-1","title":"Stack memory zeroing","text":"Both kernel and userspace threads shall zero-initialize all stack memory before use.\n\n* Reference: TR-LMII\n* Objective: Prevent attacker from exploiting erroneous use of uninitialized stack memory\n* Activities: For each of kernel and userspace, sequentially call 2 functions that allocate the same amount of memory, fill the first with non-zero values and return, and during second function call, read the stack contents back\n* Verdict: stack contents are all zero on second call\n* Evidence: contents of stack before the first function return, contents of stack during the second function call"},{"id":"MI-MZRO-2","title":"Heap memory zeroing","text":"Both kernel and userspace threads shall zero-initialize all heap memory before use.\n\n* Reference: TR-LMII\n* Objective: Prevent attacker from exploiting erroneous use of uninitialized heap memory\n* Activities: For each of kernel and userspace, allocate heap memory, fill with a non-zero value, free it, allocate it again in a deterministic way to get the same heap region, and read back the contents\n* Verdict: memory contents are all zero on second call\n* Evidence: contents of allocated memory before the free, contents of allocated memory after second allocation"},{"id":"MI-MRWX-1","title":"Prevent writes to executable and read-only data memory","text":"Both kernel and userspace threads shall reject writes to executable and read-only data memory\n\n* Reference: TR-LMII\n* Objective: Prevent writes to executable and read-only data memory\n* Activities: For each of kernel and userspace, for each portion of executable and non-writable data regions, write to it"},{"id":"MI-MRWX-2","title":"Prevent execution of non-kernel code memory","text":"Kernel threads shall prevent execution of non-kernel code memory.\n\n* Reference: TR-LMII\n* Objective: Mitigate exploits that use execution of arbitrary memory\n* Activities: For each class of non-code memory in the kernel (e.g. stack, heap, read-only data), copy a trivial return-only function into the memory, and attempt to execute each one"},{"id":"MI-ASLR","title":"Address space layout randomization","text":"The product shall enable Address Space Layout Randomization (ASLR) by default for all executables, including the kernel, if any.\n\n  * Applicability: Platform has an MMU and product implements virtual memory\n  * Reference: TR-LMII\n  * Objective: Exploit mitigation\n  * Preparation: None\n  * Activities: For every executable, examine the object file to determine if ALSR is enabled. For one non-kernel executable (if any) and one kernel executable (if any), run the executable twice and read the base addresses of the text, stack, heap, and shared libraries where applicable.\n  * Verdict: All executables have ALSR enabled, base addresses collected for executables differ between runs => PASS, else FAIL\n  * Evidence: Output of scan for ALSR enabled, base addresses collected"},{"id":"MI-MRCO","title":"Mitigate reference counter overflow","text":"Both kernel and userspace threads shall mitigate the effects of reference counter overflows\n\n* Reference: TR-LMII\n* Objective: Prevent exploitation of bugs in reference counting to overflow the counter to zero, causing a free and subsequent use-after-free accesses\n* Activities: For each of kernel and userspace, set resource reference counter to 1 less than maximum representable value, increment it twice\n* Verdict: reference counter does not overflow and resource is permanently pinned (no longer can be freed)\n* Evidence: test output showing reference counter values before and after the operation, allocation status of the resources"},{"id":"MI-NKAM","title":"Prevent unintentional kernel access to userspace memory","text":"Kernel threads shall prevent cross-privilege memory access.\n\n* Applicability: Product has multiple privilege levels\n* Reference: TR-LMII\n* Objective: Mitigate exploits that use kernel privileges to access arbitrary userspace memory\n* Activities: For each of read, write, and execute operations, use a kernel thread to attempt to use the operation on memory regions that are mapped to a different privilege level without going through dedicated memory access routines\n\nGuidance: The most common privilege levels are kernel and userspace."},{"id":"MI-PLLC","title":"Prevent linked list corruption","text":"Both kernel and userspace threads shall check the consistency of the previous and next pointers it manipulates when adding or deleting an item to or from a linked list and reject the operation if they are not consistent.\n\n* Reference: TR-LMII\n* Objective: Prevent linked list corruption\n* Activities: For each of kernel and userspace, add or delete an item to an uninitialized list"},{"id":"MI-CFIN","title":"Control flow integrity","text":"Both kernel and userspace threads shall protect saved function and return pointers from overwrite\n\n* Reference: TR-LMII\n* Objective: Mitigate exploits by preventing overwrite of function and return pointers\n* Activities: For each of kernel and userspace, save a function pointer to the heap, overwrite it with a different function, make indirect call to the saved function pointer, then repeat but with a return address that was stored to the stack\n\nGuidance: This mitigation can be implemented via software (e.g. ASan) or hardware (e.g. Pointer Authentication), or validating transitions of expected control flow graph (e.g. KCFI, Shadow Stack)."},{"id":"MI-MPMT","title":"Memory protection using memory tagging","text":"Both kernel and userspace threads shall use hardware-supported memory tagging to reject erroneous memory accesses.\n\n* Reference: TR-LMII\n* Objective: Mitigate exploits by preventing memory errors\n* Activities: For each of kernel and userspace, allocate 2 adjacent memory regions with separate tags. Attempt to read and write memory with a positive offset into trailing region from leading region's tagged pointer. Attempt to read and write with negative offset into leading region using trailing region's tagged pointer. Free a region and read and write to the region using the original tagged pointer."}]}]},{"clause":"5.2.7","title":"TR-MINI: Minimize impact on other devices and services","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-MINI","requirement":"The product shall implement appropriate mitigations to minimize impact on other devices and services.\n\n**Editor's Note:** We hope that there will be additional contributions to this section in the future.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-MDOC","title":"Document transfer of risk of minimizing impact to operating environment","text":"The product shall be accompanied by documentation informing the user of the transfer of risk for minimizing impact on other devices and services.\n\n  * Reference: TR-MINI\n  * Objective: Minimize impact on other devices and services\n  * Activities: Examine the documentation\n  * Verdict: Transfer of risk documented in a manner appropriate to the user => PASS, otherwise FAIL\n  * Evidence: Documentation, analysis of documentation"},{"id":"MI-MNET","title":"Minimize negative impact of network transmission","text":"The product shall minimise its negative impact on other products or services via the data it transmits on the network. Each source of network data shall be documented, along with the ways it can interfere with other products or services, and methods the product uses to minimise that interference.\n\n  * Reference: TR-MINI\n  * Objective: Minimise negative impact on others\n  * Preparation: List all sources of transmitted network data on the product\n  * Activities: For each method of sending network data, examine the documentation of the ways it can interfere with other products or services, and what methods the product uses to minimise that interference\n  * Verdict: Every method of sending network data is documented with ways it can interface and methods used to minimise => PASS, otherwise FAIL\n  * Evidence: All configuration files for network services, documentation of network services and their impact and methods to minimise it, internal lists of listening ports, results of an external port scan"},{"id":"MI-MAMP","title":"Minimize negative impact of network traffic amplification","text":"The product shall mitigate abuse of network services that amplify network traffic in manner that can be used to attack other devices. Each network service and its associated mitigations shall be documented.\n\n  * Reference: TR-MINI\n  * Objective: Minimise negative impact on others\n  * Preparation: List all network services that return responses larger than the recieved packet without authorization of the source\n  * Activities: For each network service, examine the documentation of the steps taken to limit access, rate-limit, or otherwise mitigate the use of the service in traffic amplication attacks\n  * Verdict: Every method of sending network data is documented with how its impact on others has been mitigated => PASS, otherwise FAIL\n  * Evidence: All configuration files for network services, documentation of network services and their impact and methods to minimise it, internal lists of listening ports, results of an external port scan, calculation of traffic amplification factors"}]}]},{"clause":"5.2.8","title":"TR-SDEF: Secure by default configuration","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-SDEF","requirement":"The product shall operate in a secure configuration by default.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-ADEF","title":"Authorization required by default to access security-relevant assets","text":"The product's default state shall require appropriate authorization to access all security-relevant assets. Appropriate authorization depends on the use case and the asset. For example, an autogenerated device-specific cryptographic key should not be readable without appropriate authorization.\n\n  * Reference: TR-SDEF\n  * Objective: Find any unauthorized access to security relevant assets in default configuration\n  * Preparation: List all interfaces allowing access to security-relevant assets\n  * Activities: For each interface, attempt to access security-relevant assets without appropriate authorization and record whether access was allowed or not\n  * Verdict: If every interface does not allow access without appropriate authorization => PASS, otherwise => FAIL\n  * Evidence: List of interfaces allowing access to security-relevant assets, record of activities used to attempt unauthorized access to security-relevant assets, log of results of attempts\n  * Applicability: if the product's intended purpose is for integration into another product, this mitigation may be implemented by the integrator"},{"id":"MI-PDDI-1","title":"Document how to protect access to debug and management interfaces","text":"All debug and management interfaces on the product shall be documented, and the documentation shall specify means to protect or disable them.\n\n  * Applicability: This mitigation is for products intended for integration into subsequent products.\n  * Reference: TR-SDEF\n  * Objective: Secure by default\n  * Preparation: Examine the documentation for how to protect or disable the debug/management interfaces of the product\n  * Activities: Examine the product for undocumented debug/management interfaces, then follow the instructions in the documentation to disable or protect each documented interface, then attempt to access the interface without authorization\n  * Verdict: All debug/management interfaces are documented as to how to disable or protect them, and no interfaces are accessible without authorization after following the documentation to protect or disable them => PASS, otherwise => FAIL\n  * Evidence: Pictures of the product, list of discovered interfaces, comparison with documentation, notes as to which are documented how to disable/protect, logs of protect/disable actions, logs of attempts to access interfaces after protected or disabled"},{"id":"MI-PDDI-2","title":"Protect or disable physical access to debug and management interfaces","text":"All debug and management interfaces which can be accessed by an agent with physical access to the device the product is installed on shall be protected or disabled by default, unless necessary for backward compatibility. Documentation regarding the removal of such protections by an appropriately sophisticated user may be provided, and shall include information regarding the risks.\n\n  * Reference: TR-SDEF\n  * Objective: Secure by default\n  * Preparation: Examine the documentation of the network- and localhost-accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces\n  * Activities: As an unprivileged process running on the system, attempt to access the system's local debug and management interfaces and make unauthorized changes. Additionally, scan accessible memory and inter-process-communication mechanisms for undocumented debug and management interfaces.\n  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL\n  * Evidence: List of interfaces, log of attempts to access"},{"id":"MI-PDDI-3","title":"Protect or disable local software access to debug and management interfaces","text":"All debug and management interfaces which can be accessed by processes running on the system shall be protected or disabled by default, unless necessary for backward compatibility. Documentation regarding the removal of such protections by an appropriately sophisticated user may be provided, and shall include information regarding the risks.\n\n  * Reference: TR-SDEF\n  * Objective: Secure by default\n  * Preparation: Examine the documentation of the network- and localhost-accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces\n  * Activities: As an unprivileged process running on the system, attempt to access the system's local debug and management interfaces and make unauthorized changes. Additionally, scan accessible memory and inter-process-communication mechanisms for undocumented debug and management interfaces.\n  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL\n  * Evidence: List of interfaces, log of attempts to access"},{"id":"MI-PDDI-4","title":"Protect or disable network access to debug or management interfaces","text":"All debug and management interfaces accessible via the network shall be protected or disabled by default, unless necessary for backward compatibility. Documentation regarding the removal of such protections by an appropriately sophisticated user may be provided, and shall include information regarding the risks.\n\n  * Reference: TR-SDEF\n  * Objective: Secure by default\n  * Preparation: Examine the documentation of the network accessible interfaces of the product and follow the instructions to mitigate the risk of any necessary unprotected or enabled interfaces\n  * Activities: Using a network scanner, scan the product for both documented and undocumented debug or remote management interfaces and determine whether they are enabled or protected\n  * Verdict: No undocumented interfaces are found and no interfaces can be accessed without authorization other than those documented as necessary and the instructions to the user are sufficient => PASS, otherwise => FAIL\n  * Evidence: List of interfaces, log of attempts to access"}]}]},{"clause":"5.2.9","title":"TR-SCUD: Secure updates","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-SCUD","requirement":"The product shall be securely updateable by the user.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-SCHL","title":"Low security updates provided by operational environment","text":"The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the \"Low\" security level for the product supplying it.\n\n  * Reference: TR-SCUD\n  * Objective: Secure updates\n  * Activities: Assess the documentation provided with the product\n  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL\n  * Evidence: Documentation and analysis of completeness"},{"id":"MI-SCHM","title":"Medium security updates provided by operational environment","text":"The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the \"Medium\" security level for the product supplying it.\n\n  * Reference: TR-SCUD\n  * Objective: Secure updates\n  * Activities: Assess the documentation provided with the product\n  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL\n  * Evidence: Documentation and analysis of completeness"},{"id":"MI-SCHH","title":"High security updates provided by operational environment","text":"The technical documentation provided with the product shall document that the operational environment shall provide a method of receiving notifications of secure updates from the manufacturer, retrieving the updates, verifying the updates, and applying them to the product. The secure update method shall satisfy the \"High\" security level for the product supplying it.\n\n  * Reference: TR-SCUD\n  * Objective: Secure updates\n  * Activities: Assess the documentation provided with the product\n  * Verdict: Documentation describes requirements for the secure updates provided by the operational environment => PASS, otherwise FAIL\n  * Evidence: Documentation and analysis of completeness"}]}]},{"clause":"5.2.7","title":"TR-AUTH: Authentication and access control","overview":"**Editor's Note:** We anticipate that future revisions of this document will include state-of-the-art authentication requirements. This section should reference authentication and access control standards.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[]},{"clause":"5.2.7","title":"TR-CDST: Confidentiality of data stored on the product","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-CDST","requirement":"The product shall protect data stored on the product from unauthorized access.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-CDST","title":"Protect confidentiality of data stored on the product","text":"**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.\n\nThe product shall protect data stored on the product from unauthorized access.\n\n  * Reference: TR-CDST\n\n  * Objective: Confidentiality of data\n\n  * Preparation: List all types of data that may be stored on the product that should not be readable without authorization, what methods of ensuring confidentiality are appropriate for each type, all methods of accessing that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that access method\n\n  * Activities: For each type of data and each access mechanism, determine the method of ensuring confidentiality used, and attempt to read the data without authorization\n\n  * Verdict: If all methods of ensuring confidentiality match the type of the data stored, and all the attempts to read confidential data without authorization fail => PASS, otherwise => FAIL\n\n  * Evidence: Logs of determination of type of data and method of confidentiality and attempts to read confidential data without authorization\n\nGuidance: Data may be protected by the environment, permissions, encryption, salting and hashing, offline storage, or hardware-backed secrets."}]}]},{"clause":"5.2.8","title":"TR-CDTX: Confidentiality of data transmitted by product","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-CDTX","requirement":"The product shall protect data transmitted by the product from unauthorized access.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-CDTX","title":"Protect confidentiality of data transmitted by product","text":"**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.\n\nThe product shall protect data transmitted by the product from unauthorized access.\n\n  * Reference: TR-CDTX\n\n  * Objective: Confidentiality of data\n\n  * Preparation: List all types of data that may be transmitted on the product that should not be readable without authorization, what methods of ensuri\nng confidentiality are appropriate for each type, all methods of accessing that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that access method\n\n  * Activities: For each type of data and each access mechanism, determine the method of ensuring confidentiality used, and attempt to read the data without authorization\n\n  * Verdict: If all methods of ensuring confidentiality match the type of the data transmitted, and all the attempts to read confidential data without authorization fail => PASS, otherwise => FAIL\n\n  * Evidence: Logs of determination of type of data and method of confidentiality and attempts to read confidential data without authorization\n\nGuidance: Data transmitted may be protected by the environment or encryption."},{"id":"MI-DOCC","title":"Document transfer of risk of confidentiality of data transmitted by product","text":"The product shall be accompanied by documentation informing the user of the transfer of risk for protecting the confidentiality of data transmitted by the product.\n\n  * Reference: TR-CDTX\n  * Objective: Protect data confidentiality\n  * Activities: Examine the documentation\n  * Verdict: Transfer of risk documented in a manner appropriate to the user => PASS, otherwise FAIL\n  * Evidence: Documentation, analysis of documentation"}]}]},{"clause":"5.2.9","title":"TR-CRYP: Encryption","overview":"**Editor's Note:** We anticipate that future revisions of this document will include state-of-the-art encryption requirements, including references to appropriate encryption standards not already included in the Agreed Cryptographic Mechanism and CRA Addendum.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[]},{"clause":"5.2.10","title":"TR-IDST: Integrity of data stored on the product","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-IDST","requirement":"The product shall protect the integrity of data stored on the product from unauthorized modification and report corruption.\n\nGuidance: Integrity may be protected by the environment, permissions, duplication, backups, and/or checksums.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-IDST","title":"Protect integrity of data stored on the product","text":"**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.\n\nThe product shall protect the integrity of data stored on the product from unauthorized modification.\n\n  * Reference: TR-IDST\n\n  * Objective: Integrity of data\n\n  * Preparation: List all types of data that may be stored on the product that should not be modifiable without authorization, what methods of protecting integrity are appropriate for each type, all methods of modifying that data available to an attacker based on the risk assessment, and what the allowable authorization methods are for that modification method\n\n  * Activities: For each type of data and each access mechanism, determine the method of protecting integrity used, and attempt to modify the data without authorization\n\n  * Verdict: If all methods of ensuring integrity match the type of the data stored, and all the attempts to modify protected data without authorization fail => PASS, otherwise => FAIL\n\n  * Evidence: Logs of determination of type of data and method of integrity and attempts to modify protected data without authorization"},{"id":"MI-DCST","title":"Detect corruption of data stored","text":"**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.\n\nThe product shall detect corruption of the data stored on the product.\n\n  * Reference: TR-IDST\n\n  * Objective: Integrity of data\n\n  * Preparation: List all types of data that may be stored on the product whose corruption should be detected and what methods of detecting corruption are appropriate for each type\n\n  * Activities: For each type of data and method of detecting corruption, corrupt the data in a way that the method will detect\n\n  * Verdict: If all methods of detecting corruption match the type of the data stored, and all the corruptions of data are detected => PASS, otherwise => FAIL\n\n  * Evidence: Logs of determination of type of data and corruptions of data"}]}]},{"clause":"5.2.11","title":"TR-IDTX: Integrity of data transmitted by the product","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-IDTX","requirement":"The product shall detect corruption of the data transmitted by the product.\n\nGuidance: Integrity may be protected by the environment, permissions, duplication, backups, and/or checksums.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-DCTX","title":"Detect corruption of data transmitted by the product","text":"**Editor's Note:** We have included only a high-level mitigation, and anticipate that more detailed and specific mitigations will be added later.\n\nThe product shall detect corruption of the data transmitted by the product.\n\n  * Reference: TR-IDTX\n  * Objective: Integrity of data\n  * Preparation: List all types of data that may be transmitted by the product whose corruption should be detected and what methods of detecting corruption are appropriate for each type\n  * Activities: For each type of data and method of detecting corruption, corrupt the data in a way that the method will detect\n  * Verdict: If all methods of detecting corruption match the type of the data transmitted, and all the corruptions of data are detected => PASS, otherwise => FAIL\n  * Evidence: Logs of determination of type of data and corruptions of data"}]}]},{"clause":"5.2.12","title":"TR-DMIN: Data Minimization","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-DMIN","requirement":"The product shall minimize the data processed.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-DJST","title":"Document and justify processed data","text":"All sources of data processed by the product in its secure-by-default configuration shall be documented. All sources of data processed shall have a documented rationale for why its processing is necessary for the functioning of the product in its secure-by-default configuration.\n\n  * Reference: TR-DMIN\n  * Objective: Minimize data processed\n  * Preparation: List all potential sources of data for the product. For each source of data, identify a method to detect whether the product is processing data from that source.\n  * Activities: Using the list of sources of data, and the method to detect whether the product is processing data from that source, list all sources of data processed. Compare to the documented list.\n  * Verdict: All sources of processed data are documented, including rationale => PASS, otherwise => FAIL\n  * Evidence: List of sources of data, documentation of each source of data, list of sources of data processed, connection between each discovered source of processed data to its documentation"}]}]},{"clause":"5.2.13","title":"TR-AVAI: Availability","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-AVAI","requirement":"The product shall protect the availability of essential and core functions.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-AVNT","title":"Availability of network services","text":"The product shall protect the availability of essential and core network services through mitigation of denial-of-service attacks.\n\n  * Reference: TR-AVAI\n  * Objective: Protect availability of network functions\n  * Preparation: List all network services and identify essential and core network services\n  * Activities: For each essential or core network service, examine the documentation for how the product sufficiently mitigates denial-of-service attacks for its risk assessment\n  * Verdict: Every essential or core network service is documented and the mitigations are sufficient => PASS, otherwise FAIL\n  * Evidence: All configuration files for network services, documentation of network services and the ways to mitigate a denial-of-service attack on it, internal lists of listening ports, results of an external port scan"},{"id":"MI-WDOG","title":"Watchdog and self-initiated reset","text":"The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.\n\n  * Reference: TR-AVAI\n  * Objective: Availability\n  * Preparation: Document the conditions that indicate the product cannot perform its functions\n  * Activities: Cause each of the conditions to occur and observe whether the product resets\n  * Verdict: Every condition triggers an automatic reset => PASS, otherwise FAIL\n  * Evidence: Documentation, log messages"},{"id":"MI-FDRP","title":"Fast packet drop","text":"> TODO: Write mitigation requiring the product to do validity checks on packets from both the network and the user in order of cheapest to most expensive so it can drop invalid packets with as little resource usage as possible."},{"id":"MI-LMEM","title":"Limit memory usage","text":"> TODO: Write mitigation requiring the product limit memory usage triggered by user input via network or local access."},{"id":"MI-FAIR","title":"Fair resource usage and prioritization","text":"> TODO: Write mitigation requiring the product implement some form of ensuring fair resource usage by multiple sources of input, including the ability to prioritize some sources of input."},{"id":"MI-DOST","title":"Document risk transfer to operational environment for denial of service","text":"> TODO: Write mitigation documenting that the operational environment must provide denial of service protection, such as an external or internal firewall, fair queueing or filtering, a proxy, etc."}]}]},{"clause":"5.2.14","title":"TR-LMAS: Minimize exposed interfaces","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-LMAS","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.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-JSTY","title":"Document and justify exposed interfaces","text":"All exposed interfaces on the product in any state that is part of its reasonably foreseeable use or misuse in its secure-by-default configuration shall be documented. Every interface shall have a documented rationale for why its exposure is necessary for the functioning of the product in its secure-by-default configuration.\n\n  * Reference: TR-LMAS\n  * Objective: Limit attack surface\n  * Preparation: List all types of interfaces on the product that may be exposed to an attacker, whether enabled or disabled. For each type of interface, identify a method to list all exposed interfaces of that type. List all states of the product with different exposed interfaces of the product in its secure-by-default configuration, including but not limited to initial configuration, startup, in use, idle, shutdown, and reset, if applicable. For each distinct exposed interface in each state, describe the interface and why it has to be enabled by default.\n  * Activities: Using the list of types of interfaces, the list of states of the product, and the method to list all exposed interfaces of that type, list all exposed interfaces in each state. Compare to the documented list.\n  * Verdict: All discovered interfaces are documented, including rationale => PASS, otherwise => FAIL\n  * Evidence: List of types of interfaces, list of product states, documentation of each exposed interface, output of methods to list all exposed interfaces, connection between each discovered interface to its documentation"}]}]},{"clause":"5.2.15","title":"TR-LOGG: Logging and monitoring","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-LOGG","requirement":"The product shall record security-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-LOGG","title":"Logging","text":"The product shall record log messages indicating security-relevant internal events in an internal or external log. The log messages shall not include any confidential information such as PII, secrets, or credentials, or any information which might reasonably be expected to include such items.\n\n  * Reference: TR-LOGG\n  * Objective: Monitoring and recording security-relevant events\n  * Preparation: List all types of security-relevant internal events\n  * Activities: For each type of security-relevant internal event, trigger the event\n  * Verdict: For each triggered event, the log contains a message indicating the event, log message does not include any information likely to be confidential => PASS, otherwise FAIL\n  * Evidence: Method of triggering events, log messages with annotations\n\nGuidance: One type of event whose log message must take care to not accidentally include a secret is failed password authentication attempts. Since people often type their password into the username field, including the username field in the log message may result in including a secret in the log message."}]}]},{"clause":"5.2.16","title":"TR-SCDL: Secure deletion","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-SCDL","requirement":"The product shall provide a method of deleting all user data and settings and resetting the product to its secure-by-default configuration.\n\nGuidance: Overwriting all user-writable storage or encrypting all user data and deleting the key are two secure deletion mechanisms.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-RSET","title":"Secure deletion via reset","text":"The product shall reset to its secure-by-default state after a power cycle or reset command.\n\n  * Applicability: Product has the capability for the user to write data and/or settings\n  * Reference: TR-SCDL\n  * Objective: Secure deletion\n  * Preparation: Document every kind of stored data or setting that may be changed by the user on the product, how to store it on the product, and how to read it from the product\n  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, power cycle or reset the product, and read each kind of data again\n  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS\n  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one"},{"id":"MI-INST","title":"Secure deletion via reinstallation","text":"The product shall reset to its secure-by-default state after a reinstallation that securely deletes all previous user data or settings.\n\n  * Applicability: Product has the capability for the user to write data and/or settings\n  * Reference: TR-SCDL\n  * Objective: Secure deletion\n  * Preparation: Document every kind of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product\n  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, reinstall the product with the secure delete option, and read the data or settings again\n  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS\n  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one"},{"id":"MI-DELE","title":"Secure deletion via secure deletion function","text":"The product shall reset to its secure-by-default state after the secure deletion function is used.\n\n**Editor's Note:** this section should be clarified so that the method of deletion depends upon the sensitivity of data stored.\n\n  * Applicability: Product has the capability for the user to write data and/or settings\n  * Reference: TR-SCDL\n  * Objective: Secure deletion\n  * Preparation: Document every kind of data or setting that may be stored and changed by the user on the product, how to store it on the product, and how to read it from the product\n  * Activities: For each kind of user data or setting that may be stored and changed by the user on the product, write an instance of the data or setting stored on the product that is different from the default and read it from the product; once all kinds of data have been written and read, activate the secure deletion function, and read the data or settings again\n  * Verdict: If any data or setting is the same for both of the reads => FAIL, otherwise => PASS\n  * Evidence: Record of each type of data or setting, what data or setting was written, what data or setting was returned by the first read, and what data or setting was returned by the second read, comparison of each one"}]}]},{"clause":"5.2.17","title":"TR-SDTR: Secure data read and transfer","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-SDTR","requirement":"The product shall provide a method to read all data and settings from the product, and if provided, securely transfer data and settings to another product.","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-SDRF","title":"Secure data read from product","text":"The product shall provide a method by which an authorized user can securely read all data and settings from the product.\n\n  * Applicability: Product has the capability for the user to write data and/or settings\n  * Reference: TR-SDTR\n  * Objective: Secure data read\n  * Preparation: List all data and settings\n  * Activities: For each kind of data or setting, read the data or setting as an authorized user, then attempt read the data or setting as an unauthorized user, if any exists\n  * Verdict: All data and settings can be read by the authorized user, and no data or setting can be read by an unauthorized user => PASS, otherwise FAIL\n  * Evidence: List of data and settings, log message showing success or failure of each read by the authorized user and, if applicable, the unauthorized user"},{"id":"MI-SDTR","title":"Secure data transfer to another product","text":"If the product provides a method to transfer data and settings to another product, it shall do so securely.\n\n  * Applicability: Product has the capability for the user to write data and/or settings and to transfer them to another product.\n  * Reference: TR-SDTR\n  * Objective: Secure data transfer\n  * Preparation: Prepare methods by which an unauthorized user could read the data during transfer as outlined in the risk assessment\n  * Activities: Read the data or settings, initiate the data transfer, attempt to read or alter the transferred data and settings as an unauthorized user, read the new data and settings on the target product\n  * Verdict: No data or settings could be read or altered by an an unauthorized user, and the data and settings read from the original product and target product are the same wherever technically possible => PASS, otherwise FAIL\n  * Evidence: List of data and settings, log messages from the attempts to read or alter data as the unauthorized user, data and settings as read from the source product and as read from the target product, comparison explaining technical reasons for any differences in the two versions"}]}]},{"clause":"5.2.18","title":"TR-VULH: Vulnerability handling","overview":"","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"TR-VULH","requirement":"The product shall have vulnerability handling processes compliant with [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\".","applicability":{},"applicabilityText":"Per clause 5.1.1: \"Not all requirements are necessary for all products. The mapping table at the end of each requirement enumerates the set of risk factors and product use cases for which the requirements are necessary. See Annex C for more information.\" This interim draft carries no per-requirement applicability tables; clause 5.3 assigns MITIGATIONS to security profiles instead (see draftGaps).","assessment":null,"mitigations":[{"id":"MI-VULH-1","title":"Vulnerability Handling in the Product","text":"The product shall have vulnerability handling processes compliant with [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\".\n\n  * Applicability: (for requirements that depend on a feature)\n  * Reference: TR-VULH\n  * Objective: Vulnerability handling\n  * Activities: Review documentation associated with vulnerability handling.\n  * Verdict: Vulnerability handling documentation is compliant with [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\" => PASS, otherwise FAIL\n  * Evidence: Vulnerability handling documentation, comparison with [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\""},{"id":"MI-VULH-2","title":"Enabling Vulnerability Handling in Integrated Products","text":"When the product is intended for integration into subsequent products in a supply chain, system vulnerabilities may have a particularly high impact on the security characteristics of the final product. Therefore, manufacturers of operating systems intended for integration in subsequent products have a responsibility to enable the vulnerability handling processes of manufacturers which depend upon them. This is accomplished by sharing, as appropriate to the specific risks, details of the operating system's components to enable downstream manufacturers to participate in coordinated vulnerability handling procedures described in [3] prEN 40000-1-3: \"Cybersecurity requirements for products with digital elements – Vulnerability Handling\".\n\n  * Applicability: any operating system intended for integration in subsequent products, rather than use by an end-user\n  * Reference: TR-VULH\n  * Objective: Vulnerability handling\n  * Activities: Review product's SBOM for detailed lists of third-party components and verify the accuracy of identifiers of those components. If applicable and permissible, apply scanning and analysis techniques to the product to verify that the supplied SBOM is accurate and complete.\n  * Verdict:  Product's SBOM contains accurate identifiers for third-party components which can be verified from appropriate sources and unlisted third-party components are not discovered through product inspection => PASS, otherwise FAIL\n  * Evidence: Logs from product analysis and comparison to supplied SBOM"}]}]}],"rdps":{"applicability":"","families":[],"requirements":[]},"threats":[{"id":"TH-UEVU","title":"Unknown exploitable vulnerabilities","description":"Attacker may use unknown exploitable vulnerabilities in the product implementation to get unauthorized access to product assets."},{"id":"TH-KEVU","title":"Known exploitable vulnerabilities","description":"Attacker may use known exploitable vulnerabilities in the product implementation to get unauthorized access to product assets."},{"id":"TH-UAPP","title":"Unauthorized access to product assets via unprotected physical interfaces in default configuration","description":"Attacker may use unprotected debug or management interfaces to get unauthorized access to product assets via physical access in the default configuration of the product."},{"id":"TH-UAPS","title":"Unauthorized access to product assets via unprotected local software access in default configuration","description":"Attacker may use unprotected debug or management interfaces to get unauthorized access to product assets via local software access in the default configuration of the product."},{"id":"TH-UAPN","title":"Unauthorized access to product assets via unprotected network interfaces in default configuration","description":"Attacker may use unprotected debug or management interfaces to get unauthorized access to product assets via the network in the default configuration of the product."},{"id":"TH-UADT","title":"Unauthorized access to confidential data transmitted","description":"Attacker may use network access to get unauthorized access to confidential data transmitted by the product."},{"id":"TH-PDOS","title":"Denial of service attack on product functions via user or network access","description":"Attacker may use user or network access for a denial-of-service attack on product functions."},{"id":"TH-DDOS","title":"Denial of service attack on other products via exploitation of vulnerabilities or unauthorized use of product functions","description":"Attacker may use the network to exploit vulnerabilities in the product to attack other products."},{"id":"TH-MQSE","title":"Masquerading authorized server","description":"Attacker may masquerade as an authorized server to get unauthorized access to product assets."},{"id":"TH-LEAK","title":"Data leak through side channels","description":"Attacker may use the ability to run arbitrary software on the product to get unauthorized read access to confidential data."}],"draftGaps":["TR-SCUD: clause 5.2.9 contains a bare TODO heading (5.2.9.5 — the draft notes it awaits a submission from an unavailable ETSI member).","TR sections without any Requirement text in this interim draft: TR-AUTH, TR-CRYP — TR-AUTH (\"future revisions will include state-of-the-art authentication requirements\") and TR-CRYP (\"waiting on the cross-vertical cryptography approach\"; there is no Annex K). They are kept as empty topics, not as answerable requirements.","Clause numbering collides in this draft (three sections numbered 5.2.7, two 5.2.8, two 5.2.9, and two mitigation headings numbered 5.2.8.4); requirements and mitigations are identified by their TR-/MI- codes, which are unique.","assessment criteria drafted for only 2 of 19 requirements: only TR-MSAF and TR-LMII carry a requirement-level assessment block (their shared \"Default Preparation, Verdict, and Evidence\"); the other 17 requirements have assessment: null. Assessment prose does exist per MITIGATION (bulleted Objective/Preparation/Activities/Verdict/Evidence inside each entry of a requirement's mitigations list, preserved verbatim), because this draft has not yet separated clause-6 assessment criteria from clause-5 requirements — clause 6 (Conformity Assessment) is empty apart from an editor's note saying the guidance stays adjacent to the requirements for now.","Clause 5.3 (Risk Mitigation Sets) assigns mitigations per security profile SP-* using bare codes, several of which clause 5.2 never defines (SUAP, SUAO, SUVP, SUOE, SUDC, AUTH, CRYP, VULH, DMIN, KEVT-vs-SCAN alternates and MSAF-*/MZRO-*/MRWX-* wildcards). Per-use-case applicability therefore cannot be derived reliably and is not fabricated: every loaded requirement is treated as applicable (applicability {}), and the profile tables remain in the draft for manual consultation.","Four availability mitigations under TR-AVAI are TODO stubs with no normative text yet (MI-FDRP, MI-LMEM, MI-FAIR, MI-DOST) — their verbatim TODO lines are preserved in the mitigations list.","Annex D.4 names risk-transfer mitigations that clause 5.2 does not define (MI-SUDC, MI-SUOE, MI-SUAO) — dangling references in this interim draft.","This draft has no Annex K (cryptography) and no Annex R (RDPS); rdps is loaded empty. Annex A maps by CRA requirement description rather than Annex I item numbers, and flags AUTH and CRYP as 'waiting on cross-vertical'.","The draft's ids are TR-XXXX (requirements) and MI-XXXX (mitigations); it contains no REQ-prefixed ids. MI-SCFS references \"TR-SDDV\", a code defined nowhere — the surrounding section is TR-SSDD.","Annex C numbers its threats C.4.3–C.4.7 then C.4.9–C.4.13 — C.4.8 does not exist in this interim draft; the 10 published threats are loaded."]}