{"packId":"en-304-622","packVersion":"0.1.0","standard":{"reference":"ETSI EN 304 622","title":"Cyber Resilience Act (CRA) requirements for Security Information and Event Management (SIEM) products","status":"INTERIM DRAFT — ETSI open consultation; subject to substantial change before publication (target: second half of 2026). Not cited in the Official Journal: conformance confers NO presumption of conformity today.","sourceUrl":"https://labs.etsi.org/rep/stan4cra/en-304-622","sourceCommit":"cf3cc71e5ae0","retrievedAt":"2026-08-31","license":"BSD-3-Clause, © 2025 ETSI. Redistributed with attribution as the license requires; the verbatim requirement and assessment 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":"Security information and event management (SIEM) systems","note":"Attaches to a product whose CRA classification matched the Annex III SIEM item, or manually."},"scope":"The present document specifies technical requirements and corresponding assessment criteria for Security Incident Event Management related to cybersecurity.\n\nThe products with digital elements in scope, thereafter “SIEM” or “SIEM systems”:\n\n- are specified within the “technical description” of the “category of product” number 7 by the Commission Implementing Regulation (EU) 2025/2392 [i.2\\] as:\n  > Products with digital elements that collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes, such as threat and incident detection, forensic analysis or compliance purposes.\n- are only covered within the product context described in [clause 4](#product-context).\n\nThe present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [i.1\\] Annex I Part I under the conditions identified in annex A.\n\nSIEM systems intended for use in the industrial OT (Operational Technology) domain are excluded from the scope of the present document, see prEN 50770 series [i.8\\].","applicabilityIntro":"The technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.\n\nThe requirements in this section are unconditionally applicable, unless specifically indicated with a conditional phrasing, or the functionality is implemented with RDPS.\n\n### 5.1.2 Applicability of Annex K\n\nWhere the product relies on cryptographic mechanisms for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in Annex K.\n\n### 5.1.3 Applicability of Annex R\n\nWhere the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in Annex R.\n\nNOTE: Annex R specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.","useCases":[{"id":"UC-1-RESEARCH","title":"Research SIEM","description":"* Goal: Provide minimum functionality for research or training\n* Description:\n  * Examples: Simple SIEM for a collection of containers used for research or training\n  * Function: Monitor simulated elements\n  * Network connectivity: Isolated private network\n  * Sensitivity of product functions: Low\n  * Number of monitored assets: Low\n  * User administration skill: High"},{"id":"UC-2-HOME","title":"Home SIEM","description":"* Goal: Monitor a small number of home devices\n* Description:\n  * Examples: Homelab SIEM\n  * Function: Monitor home devices for anomalies\n  * Network connectivity: Filtered private network\n  * Sensitivity of product functions: Medium\n  * Number of monitored assets: Low\n  * User administration skill: High"},{"id":"UC-3-FLEET","title":"Fleet monitoring","description":"* Goal: Monitor a homogenous fleet of devices in a controlled area\n* Description:\n  * Examples: Servers in a data centre, phones in a test lab\n  * Function: Monitor health and network traffic within a facility\n  * Network connectivity: Filtered private\n  * Sensitivity of product functions: High\n  * Number of monitored assets: High\n  * User administration skill: High"},{"id":"UC-4-IOT","title":"IoT monitoring","description":"* Goal: Monitor large fleet of IoT devices\n* Description:\n  * Examples: SIEM for network-connected washing machines\n  * Function: Monitor a large fleet of appliances\n  * Network connectivity: Public network\n  * Sensitivity of product functions: Medium\n  * Number of monitored assets: High\n  * User administration skill: Medium"}],"craMap":[{"craRef":"Annex I, Part 1, (1)","clauses":"5"},{"craRef":"Annex I, Part 1, (2)(a)","clauses":"5.3"},{"craRef":"Annex I, Part 1, (2)(b)","clauses":"5.4"},{"craRef":"Annex I, Part 1, (2)(c)","clauses":"5.5"},{"craRef":"Annex I, Part 1, (2)(d)","clauses":"5.6"},{"craRef":"Annex I, Part 1, (2)(e)","clauses":"5.7"},{"craRef":"Annex I, Part 1, (2)(f)","clauses":"5.8"},{"craRef":"Annex I, Part 1, (2)(g)","clauses":"5.9"},{"craRef":"Annex I, Part 1, (2)(h)","clauses":"5.10"},{"craRef":"Annex I, Part 1, (2)(i)","clauses":"5.11"},{"craRef":"Annex I, Part 1, (2)(j)","clauses":"5.12"},{"craRef":"Annex I, Part 1, (2)(k)","clauses":"5.13"},{"craRef":"Annex I, Part 1, (2)(l)","clauses":"5.14"},{"craRef":"Annex I, Part 1, (2)(m)","clauses":"5.15"}],"topics":[{"clause":"5.2","title":"Appropriate level of cybersecurity","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (1).\n\nIn alignment with the Cyber Resilience Act Annex I Part I (1), this section addresses overarching risks and mitigations regarding the secure design and development of the product that are not specifically treated by other categorical essential requirements (such as confidentiality, access control, or security updates). The requirements herein ensure the final product itself embodies security by design.","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-ALC-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-ALC-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-ALC-01","requirement":"All cybersecurity-relevant parts of the product shall implement methods to validate untrusted inputs and mitigate the effects thereof.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Secure design and development.","preparation":"Identify all sources of untrusted input to the product. For each source of untrusted input, identify fields in the inputs that are used for:\n\n  * calculation of memory accesses: length, index, hash table lookup values, packet reassembly\n  * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations\n  * incrementing or decrementing of internal counters: packet counters, event counters\n  * creating or populating internal data structures: parameters for creating an array of packet descriptors\n\nFor each identified field, identify a set of inputs that contains at least one input that fulfills each of the following descriptions, if and only if the description is applicable to the field, the described values exist, and they are possible to send as input:\n\n  * the maximum **valid** value or length of input for that field\n  * the minimum **valid** value or length of input for that field\n  * the next value/length of input above the minimum valid value\n  * the next value/length of input below the minimum valid value\n  * the next value/length of input below the maximum valid value\n  * the next value/length of input above the maximum valid value\n\n  * the maximum **possible** value or length of input for that field\n  * the minimum **possible** value or length of input for that field\n  * the next value/length of input above the minimum possible value\n  * the next value/length of input below the maximum possible value\n\n  * a representative selection of other valid and invalid values or input lengths for that field\n  * values that could cause overflow or underflow of internal counters\n  * values that are inconsistent with other values in the input\n\nIdentify the acceptable behavior(s) of the product in response to the inputs that would be consistent with validating the input and mitigating the cybersecurity risks of untrusted input. Identify a method of sending these inputs to the product and recording the responses. Set up this testing environment.","activities":"For every identified input, send the input to the product and record its response.","verdict":"PASS if for every identified input, the product responds in a manner consistent with the identified acceptable behavior.\n\nOtherwise FAIL","evidence":"* Description of identified fields of untrusted input\n* Analysis of sources of untrusted input for identified inputs\n* Sufficiency analysis of analysis of untrusted sources of input\n* Description of test inputs and acceptable behaviors\n* Logs of testing inputs and recording behavior\n* Sufficiency analysis of testing logs","guidance":"Assessment can often be done with minimal effort using commonly available fuzzer or security testing tools or adapting an existing product test suite. It can also be done by hand.\n\nAssessment can often be done with minimal effort using commonly available fuzzer or security testing tools or adapting an existing product test suite. It can also be done by hand.\n\nExamples of each of the types of input:\n\n  * calculation of memory accesses: length, index, hash table lookup values, packet reassembly\n  * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations\n  * incrementing or decrementing of internal counters: packet counters, event counters\n  * creating or populating internal data structures: parameters for creating an array of packet descriptors\n\nThe list of inputs to test includes some types of input that may not exist or be possible to send. For example, if the maximum **valid** value is also the maximum **possible** value, then it is not possible to send the next value higher than the maximum value. These values do not need to be tested.\n\nSecure design and development practices such as static analysis or secure compilation flags may assist in the fulfillment of this requirement by identifying potential sources of untrusted input for review, as well as automatically validating and mitigating invalid values.\n\nAcceptable behaviors might include:\n\n* Rejection of input and returning an error\n* Silent discard of input\n* Correction of input\n* Dropping client data and incrementing an error counter\n* Emitting a error event\n* Emitting a notification when a counter rolls over\n* Crashing and restarting\n* Terminating a thread"}},{"id":"REQ-ALC-02","requirement":"The product shall record all system time drift corrections as monitoring events.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Appropriate level of cybersecurity.","preparation":"1. Initialize the product with the default configuration and required credentials.","activities":"1. Set the node and the chosen monitored element to a wrong time that is off by at least an hour;\n2. Set connected system service to a wrong time that deviates from real time by at least one hour.","verdict":"PASS if **all** of the following are fulfilled:\n\n1. the product detects the drift, and\n2. the product creates a notification about the event.\n\nOtherwise FAIL","evidence":"* System notification from the logs.","guidance":""}}]},{"clause":"5.3","title":"No known exploitable vulnerabilities","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (a).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-KEV-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-KEV-01","requirement":"1. **REQ-KEV-01-1** The product shall have no known exploitable vulnerabilities discovered during testing, or\n2. **REQ-KEV-01-2** the product shall not have any known exploitable vulnerabilities discovered during testing that were reported within the previous 14 days, or the time period permitted before public disclosure as described in the vulnerability handling procedure for the product, or\n3. **REQ-KEV-01-3** the product shall have no known exploitable vulnerabilities discovered during testing that do not have associated publicly-available documentation explaining the risk and how that risk has been mitigated.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"All products and use cases shall fulfill **at least one** of the above sub-requirements, REQ-KEV-01-1, REQ-KEV-01-2, **or** REQ-KEV-01-3.\n\n> NOTE: An exploitable vulnerability's transition from “unknown” to “known” may be by its publication to the EU Vulnerability Database [i.9](#_ref_i.9), an industry-specific vulnerability database, or direct notification to the manufacturer via its own vulnerability reporting process.\n\n* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Prevent exploitation of known exploitable vulnerabilities.","preparation":"Using the product's SBOM and relevant publicly accessible vulnerability databases (e.g. [GCVE](https://gcve.eu), [EUVD](http://euvd.enisa.europa.eu)), compile a list of target components and potential known exploitable vulnerabilities. Select the appropriate testing methodology (e.g., the most comprehensive automated scanners available, or a manual penetration test plan) to verify the mitigation of these vulnerabilities.","activities":"On a new product, carry out a security update, run the tests, and compare the results with the generated list of known exploitable vulnerabilities.","verdict":"PASS if **any** of the following are fulfilled:\n\n* No vulnerabilities found, or\n* all reported vulnerabilities satisfy either the elapsed time since discovery or mitigation requirement.\n\nOtherwise FAIL","evidence":"* Documented vulnerability handling policy\n* Product SBOM\n* List of testing tools used or manual test plan\n* Test reports/scan results\n* Correlation of discovered vulnerabilities with:\n  * documentation of mitigation, or\n  * elapsed time since discovery of vulnerability.","guidance":""}}]},{"clause":"5.4","title":"Secure by default configuration","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (b).","addressedBy":["REQ-ASM-01","REQ-CON-01","REQ-CON-03","REQ-INT-01","REQ-INT-03"],"otherRequirements":[],"mappingTable":{},"requirements":[]},{"clause":"5.5","title":"Security updates","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (c).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-SU-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-SU-01","requirement":"The product shall support securely updating the product via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Prevent exploitation of known exploitable vulnerabilities.","preparation":"Identify methods the product provides for installing updates. Identify an operational environment that permits testing these methods. Set up the product in the identified operational environment. Identify a method to verify the installation of an update. Identify an update that is not yet installed on the product.","activities":"Install the identified update for the product and use the identified method to verify it.","verdict":"PASS if verification of the installation of the update succeeds.\n\nOtherwise FAIL","evidence":"* Logs of reading original and updated version of product\n* Security update file(s)\n* Logs of update installation process","guidance":"A method of assessment might be: install one version of the software, use a product-provided method of reading version of the installed product, then install a different version and read the version again."}}]},{"clause":"5.6","title":"Authentication and access control","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (d).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-AAC-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-AAC-01","requirement":"The product shall support authentication and access control to the product via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Prevent unauthorized access.","preparation":"Identify methods the product provides for authorization or access control of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require authentication or access control to protect the cybersecurity of the product. Identify any necessary configuration, inputs, or other preparation for testing authentication or access control for that asset. Set up the product in the identified operational environment.","activities":"For each method and each type of product asset identified, carry out the identified testing preparations and attempt to access the product asset without the necessary authorization.","verdict":"PASS if every attempt to access the product asset without the necessary authorization fails.\n\nOtherwise FAIL","evidence":"* Descriptions of types of product assets requiring authorization or access control\n* Records of configuration, input, and/or preparation for each test\n* Logs of access attempts and their results","guidance":""}}]},{"clause":"5.7","title":"Confidentiality protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (e).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-CON-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-CON-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-CON-03":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-CON-01","requirement":"The product shall support confidentiality protection of the ingested data via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect the ingested data confidentiality.","preparation":"Set up a monitored element and collect data from it.","activities":"Attempt to access the ingested data without valid authorization.","verdict":"PASS if access is denied.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"REQ-CON-02","requirement":"The product shall distinguish between confidentiality-protected and non-confidentiality protected channels between the server and monitored elements in a user-visible way.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Inform the user about the confidentiality protection of the sources of ingested data.","preparation":"None.","activities":"Set up a monitored element using a confidentiality-protected channel and collect data from it. Set up a monitored element using a channel without confidentiality protection and collect data from it. View, analyze, or otherwise make use of the data.","verdict":"PASS if at any point during the activities, the product informs the user that the non-confidentiality-protected data is not confidentiality protected.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":"The product may distinguish the confidentiality of sources of data at the following times:\n\n  * addition of a monitored element\n  * display of monitoring data\n  * display of processed data\n  * in an alert\n  * in a report\n  * in a log message"}},{"id":"REQ-CON-03","requirement":"The product shall cryptographically protect the confidentiality of stored secrets.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect the confidentiality of product secrets.","preparation":"Configure and use the product in a manner that results in stored secrets.","activities":"Attempt to read the stored secrets without valid authorization. Then use valid authorization to read the secrets as stored and attempt to decrypt them using materials available without valid authorization.","verdict":"PASS if the stored secrets are not read without valid authorization or decrypted without using materials available without valid authorization.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}}]},{"clause":"5.8","title":"Integrity protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (f).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-INT-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-INT-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-INT-03":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-INT-01","requirement":"The product shall support integrity protection of the ingested data via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect the ingested data integrity.","preparation":"Set up a monitored element and collect data from it. Make a copy of the data.","activities":"Attempt to modify the ingested data without valid authorization. Read the data and compare with the copy of the data taken before the attempt to modify it.","verdict":"PASS if the ingested data was not modified.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"REQ-INT-02","requirement":"The product shall distinguish between integrity-protected and non-integrity protected channels between the server and monitored elements in a user-visible way.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Inform the user about the integrity protection of the sources of ingested data.","preparation":"None.","activities":"Set up a monitored element using an integrity-protected channel and collect data from it. Set up a monitored element using a channel without integrity protection and collect data from it. View, analyse, or otherwise make use of the data.","verdict":"PASS if at any point during the activities, the product informs the user that the non-integrity-protected data is not integrity protected.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":"The product may distinguish the integrity of sources of data at the following times:\n\n  * addition of a monitored element\n  * display of monitoring data\n  * display of processed data\n  * in an alert\n  * in a report\n  * in a log message"}},{"id":"REQ-INT-03","requirement":"The product shall support integrity protection of stored secrets via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect the integrity of product secrets.","preparation":"Configure and use the product in a manner that results in stored secrets. Make a copy of the stored secrets.","activities":"Attempt to modify the stored secrets without valid authorization. Read the stored secrets and compare with the copy of the stored secrets taken before the attempt to modify it.","verdict":"PASS if the stored secrets are not read without valid authorization or decrypted without using materials available without valid authorization.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.9","title":"Data minimisation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (g).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-DM-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-DM-01","requirement":"The product shall minimize the data processing by the product.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Minimise data processed by the product.","preparation":"Determine all data processing done by the product, using as necessary:\n\n * product technical documentation\n * product functions\n * product interfaces\n * data transmitted by the product\n * data stored by the product\n * product binaries\n * source code\n * other sources of product information","activities":"For each type of data processing identified, analyse its relevance and necessity for the intended purpose of the product.","verdict":"PASS if, for every type of data processing identified, the data processed is determined to be relevant and limited to what is necessary for the intended purpose of the product.\n\nOtherwise FAIL","evidence":"* Product information used to determine what data processing the product does\n* Sufficiency analyses of relevance, limitation, and necessity of data for product purpose","guidance":"Data processed should have a clear connection to the intended purpose of the product. Some examples:\n\n* Collected log data\n* Metrics\n* Internal events\n* Performance data\n* Debug logs"}}]},{"clause":"5.10","title":"Availability protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (h).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-AP-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-AP-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-AP-03":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-AP-04":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-AP-01","requirement":"The product shall support availability protection via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Maintain service availability during denial-of-service attacks.","preparation":"None","activities":"Assess the technical documentation provided with the product.","verdict":"PASS if the technical documentation describes how the availability protection can be provided by the operational environment.\n\nOtherwise FAIL","evidence":"* Documentation\n* Analysis of documentation\n* Documentation of intended purpose","guidance":""}},{"id":"REQ-AP-02","requirement":"The product shall record log events or emit alerts when it detects ingest data being dropped.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect availability of the product.","preparation":"Configure the product and monitored elements as necessary to be able to trigger activity that exceeds the product's data ingest processing when the elements are actively producing ingest data.","activities":"Trigger the activity that exceeds the product's data ingest processing. Record the alerts and logs from the product.","verdict":"PASS if the product outputs a log message or security alert for the dropped ingest data.\n\nOtherwise FAIL","evidence":"* Description of test setup\n* Logs from product with dropped ingest data annotated","guidance":""}},{"id":"REQ-AP-03","requirement":"The product shall mitigate any impact on product availability caused by monitored elements.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect availability of the product.","preparation":"Configure the product and monitored elements as necessary to be able to trigger activity that exceeds the product's data ingest processing when the elements are actively producing ingest data. Additionally configure a well-behaved monitored element to be able to trigger activity that requires less than its share of the total data ingest capacity of the product as configured, proportionate to the number of total monitored elements.","activities":"Trigger the activity of all configured elements.","verdict":"PASS if the data from the well-behaved monitored element is fully recorded by the product, or if any data is dropped, an event is recorded indicating the lost data.\n\nOtherwise FAIL","evidence":"* Description of test setup\n* Logs from product\n* Analysis of proportion of data ingested from well-behaved monitored element\n* Analysis of events recording data dropped from well-behaved monitored element\n* Sufficiency analysis of analysis of proportion of data ingested\n* Sufficiency analysis of analysis of events recording data dropped","guidance":""}},{"id":"REQ-AP-04","requirement":"The product shall limit and fairly allocate memory usage triggered by untrusted input to maintain availability of product functions and the functions of the underlying platform and other products sharing system resources.\n\n> NOTE: The product should range-check untrusted input fields that trigger memory allocations and rate-limit or drop input that would allocate enough memory to impair the functions of any part of the system.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Maintain service availability during denial-of-service attacks.","preparation":"Identify input fields from untrusted input that are used to calculate the size of memory allocations, and create a set of inputs that, if processed as fast as possible, would significantly degrade the function of the product due to overallocation of memory.","activities":"For each set of inputs,\n\n1. send the input to the product,\n2. while simultaneously measuring the availability of the product functions and the functions of the underlying platform.","verdict":"PASS if **all** of the following are fulfilled:\n\nFor each set of inputs,\n\n* the product functions, and\n* the platform functions remain acceptably available.\n\nOtherwise FAIL","evidence":"* Set of inputs\n* Logs of measurements\n* Explanation of availability metrics","guidance":""}}]},{"clause":"5.11","title":"Non-interference","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (i).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-NI-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-NI-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-NI-01","requirement":"The product shall minimise the data originating from the product itself that is transmitted to a destination that has not been verified as requesting the transmitting data.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Minimise negative impact on other devices or services.","preparation":"Identify interfaces that may transmit data originating from the product itself in reply to incoming data to addresses that have not been verified as requesting the transmitted data. Identify network input that may cause the interface to transmit data in such a manner.","activities":"For each identified network input, transmit the input to the interface and record any data the product transmits in response. Analyse the amount of data sent in response in the context of the product function and cybersecurity risk assessment.","verdict":"PASS if the response is consistent with reasonable minimisation of data in the response.\n\nOtherwise FAIL","evidence":"* Description of identified interfaces\n* Description of methods for identifying interfaces\n* Sufficiency analaysis of methods for identifying interfaces\n* Description of identified inputs\n* Packet captures or other appropriate logs of the data transmitted\n* Sufficiency analysis of analysis of amount of data in response","guidance":""}},{"id":"REQ-NI-02","requirement":"The product shall minimize the impact to other products or services sharing data storage with the product.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":null}]},{"clause":"5.12","title":"Attack surface minimisation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (j).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-ASM-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-ASM-01","requirement":"Exposure of interfaces on the product shall be minimised in its secure-by-default configuration.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Minimise attack surface.","preparation":"Identify all exposed interfaces in the product in its secure-by-default configuration, including different run-time states such as initial configuration, startup, in use, idle, shutdown, and reset, if applicable. Use appropriate tools and methodology to search for interfaces that may have accidentally or unintentionally exposed and that could reasonably be found by a threat actor under the conditions of the manufacturer's cybersecurity risk assessment.","activities":"For each identified interface, analyse if the exposure of the interface is necessary for the product's intended purpose in its secure-by-default configuration, connecting it to specific product functions and comparing with any obvious reasonable alternatives with smaller attack surface.","verdict":"PASS if for each identified exposed interface, the analysis for exposure of the interface concludes that it is necessary and that there is no obvious reasonable alternative with smaller attack surface.\n\nOtherwise FAIL","evidence":"* Documentation of and rationale for search process for interfaces\n* Logs of searches for interfaces\n* Description of identified interfaces\n* Sufficiency analysis of rationale for interface search process\n* Analysis of necessity of and alternatives to each identified interface\n* Sufficiency analysis of necessity analysis for identified exposed interfaces","guidance":"See Clause \\[6.1.2\\] \"Guidance for identifying interfaces or data processing.\""}}]},{"clause":"5.13","title":"Exploit mitigation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (k).","addressedBy":[],"otherRequirements":["REQ-ALC-01","REQ-ALC-02","REQ-MON-01","REQ-MON-02","REQ-MON-03","REQ-AP-01","REQ-AP-02","REQ-AP-03"],"mappingTable":{"REQ-EM-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-EM-01","requirement":"The product shall detect and report loss or degradation of monitoring data from monitored elements.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Detect compromise of monitored elements.","preparation":"Set up a monitored element that regularly emits data.","activities":"Prevent the monitored element from providing ingest data to the product and observe if the product emits a notification or alert.","verdict":"PASS if the product emits a notificaiton or alert of the loss of the monitored element's ingest data.\n\nOtherwise FAIL","evidence":"* Logs of the monitored element's ingest data\n* Logs of product notifications or alerts","guidance":""}}]},{"clause":"5.14","title":"Monitoring","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (l).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-MON-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-MON-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-MON-03":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-MON-01","requirement":"The product shall record cyber-security relevant events.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Monitoring and recording cybersecurity-relevant events.","preparation":"Review the technical documentation to confirm the scope of cybersecurity-relevant events implemented in the logging mechanism.","activities":"For each type of cybersecurity-relevant event, trigger the event, and collect any log messages.","verdict":"PASS if for each triggered event, a log message is emitted that records the cybersecurity-relevant elements of the event.\n\nOtherwise FAIL","evidence":"* Method of triggering events\n* Logs of triggering events and generated log messages\n* Log messages with annotations\n* Sufficiency analysis of annotated log messages","guidance":""}},{"id":"REQ-MON-02","requirement":"The product shall protect internal log data from unauthorized access.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"* UC-1-RESEARCH: not required\n* UC-2-HOME: required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect confidentiality of internal log data.","preparation":"Use the product in a manner that produces internal log data.","activities":"Attempt to access the internal log data without valid authorization.","verdict":"PASS if access is denied.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"REQ-MON-03","requirement":"The product shall not modify internal log data in contravention to the product's log retention policy, if any.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"not-required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"This requirement applies to products with a product log retention policy.\n\n* UC-1-RESEARCH: not required\n* UC-2-HOME: not required\n* UC-3-FLEET: required\n* UC-4-IOT: required","assessment":{"objective":"Protect integrity of internal log data.","preparation":"Use the product in a manner that produces internal log data. Set a log retention policy that prevents alteration or deletion of logs.","activities":"Attempt to modify and delete the internal log data without valid authorization.","verdict":"PASS if both modification and deletion fail.\n\nOtherwise FAIL","evidence":"* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.15","title":"Factory reset and data portability","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (m).","addressedBy":[],"otherRequirements":[],"mappingTable":{"REQ-DRT-01":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"REQ-DRT-02":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"}},"requirements":[{"id":"REQ-DRT-01","requirement":"The product shall provide a function to remove all user data and settings, and provide a function to restore to its secure-by-default state.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"null","applicabilitySource":"mapping-table","assessment":{"objective":"Secure deletion of all user data and settings.","preparation":"Identify every type 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. Identify a method to securely delete user data and settings and reset the product to its secure-by-default state.","activities":"For each type of user data or setting that may be stored and changed by the user on the product:\n\n1. record the value of the setting in the secure-by-default configuration of the product\n2. write an instance of the data or setting stored on the product that is different from the default\n\nOnce all types of user data or settings have been written and read, use the identified method to delete all user data and settings and reset to a secure-by-default configuration. Record the value of each type of user data or setting again. Compare with the original records for each type of user data or setting in its secure-by-default state.","verdict":"PASS if **all** of the following are fulfilled:\n\n* All user data and settings tested have been deleted, and\n* All settings data and settings tested are restored to a secure-by-default state.\n\nOtherwise FAIL","evidence":"* Description of each type of user data or setting written\n* For each type, record of original value, written value, and value after deletion and reset to secure-by-default method\n* Comparison and analysis of different values\n* Sufficiency analysis of comparison","guidance":"Some user settings or data (e.g. dates, randomly generated values, installation logs) may differ harmlessly between different secure-by-default configurations, so a direct comparison of the initial and final values may show some differences in a conforming product."}},{"id":"REQ-DRT-02","requirement":"The product shall support secure read of all user data and settings from the product via the operational environment.","applicability":{"UC-1-RESEARCH":"not-required","UC-2-HOME":"required","UC-3-FLEET":"required","UC-4-IOT":"required"},"applicabilityText":"This requirement applies to products with the capability for the user to write data and/or settings that fall within the following use cases:\n\nnull","applicabilitySource":"mapping-table","assessment":{"objective":"Secure data read.","preparation":"Identify every type 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 using confidentiality protection provided by the operational environment.","activities":"For each type of user data or setting that may be stored and changed by the user on the product:\n\n1. record the value of the setting in the secure-by-default configuration of the product\n2. write an instance of the data or setting stored on the product that is different from the default\n\nOnce all types of user data or settings have been written and read, use the identified method to read all user data and settings. While transferring the data, attempt to read or modify it without the authorization or access necessary for the confidentiality protection provided by the operational environment Compare with written value and the original records for each type of user data or setting in its secure-by-default state.","verdict":"PASS if all user data and settings read are consistent with the user data and settings written, and the attempts read or modify the data fail.\n\nOtherwise FAIL","evidence":"* Description of each type of user data or setting written\n* For each type, record of original value, written value, and read value\n* Comparison and analysis of values\n* Sufficiency analysis of comparison","guidance":""}}]}],"annexK":{"general":"The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1.\n\nFor ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in clause K.3.2 or fulfils the criteria specified in clause K.1.1 item 2.b. For interoperability-based cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is listed in clause K.4.2. The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.","cryptoConfigAssessments":{"acm-listed":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 1) and used in the product’s default configuration are listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1\\].","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 1), including the related product function, relevant parameters where applicable, and the relevant ACM entry.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry;\n- b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable;\n- c) where the ACM entry includes lifecycle information, such as expiry date, deprecation date, migration condition or usage limitation, this information is reflected in the documentation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 1);\n- c) references to the relevant ACM entries;\n- d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable;\n- e) relevant lifecycle information from the ACM catalogue, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 1).\n- The verdict FAIL shall be assigned otherwise."},"acm-extended":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 2) and used in the product’s default configuration are either listed as ACM-extended cryptographic mechanisms in clause K.3.2 or fulfil the criteria specified in clause K.1.1 item 2.b, and are used for the claimed product function(s).","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 2), including the related product function, use case where applicable, relevant parameters where applicable, and at least one of the following:\n  - a) the relevant entry in clause K.3.2; or\n  - b) evidence that the cryptographic mechanism fulfils all applicable criteria in clause K.1.1 item 2.b.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 2) is either listed in clause K.3.2 as an ACM-extended cryptographic mechanism or supported by evidence demonstrating fulfilment of the applicable criteria in clause K.1.1 item 2.b;\n- b) the cryptographic mechanism used by the product corresponds to the mechanism listed in clause K.3.2 or described in the evidence provided under clause K.1.1 item 2.b;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.3.2 or justified under clause K.1.1 item 2.b;\n- d) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.3.2 or justified under clause K.1.1 item 2.b, where applicable;\n- e) where clause K.3.2 or the justification under clause K.1.1 item 2.b defines conditions or limitations for the use of the cryptographic mechanism, these conditions or limitations are reflected in the product’s default configuration;\n- f) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 2);\n- c) reference to the relevant entry in clause K.3.2, where the mechanism is listed in clause K.3.2;\n- d) evidence that the cryptographic mechanism fulfils the criteria in clause K.1.1 item 2.b, where compliance with clause K.1.1 item 2 is claimed on the basis of those criteria;\n- e) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.3.2 or in the justification under clause K.1.1 item 2.b, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 2).\n- The verdict FAIL shall be assigned otherwise."},"interoperability":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 3) and used in the product’s default configuration are listed as interoperability-based cryptographic mechanisms in clause K.4.2 and are used in accordance with the characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in clause K.4.2.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 3), including the related product function, use case where applicable, relevant parameters where applicable, the external specification or external requirement requiring its use, and the relevant entry in clause K.4.2.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 3) is listed in clause K.4.2 as an interoperability-based cryptographic mechanism;\n- b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in clause K.4.2;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.4.2;\n- d) the external specification or external requirement requiring the use of the cryptographic mechanism corresponds to the external specification or external requirement specified in clause K.4.2;\n- e) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.4.2, where applicable;\n- f) the conditions or limitations specified in clause K.4.2 for the use of the cryptographic mechanism are reflected in the product’s default configuration;\n- g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 3);\n- c) reference to the relevant entry in clause K.4.2;\n- d) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- e) identification of the external specification or external requirement requiring use of the cryptographic mechanism;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.4.2.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 3).\n- The verdict FAIL shall be assigned otherwise.\n\n> NOTE 1: The assessment of the external specification or external requirement itself is outside the scope of this assessment case. The assessment verifies that the external specification or external requirement is identified in clause K.4.2 and that the cryptographic mechanism is used by the product for the related product function.\n\n> NOTE 2: Documentation review is a minimum assessment activity under the present annex. Functional and/or resistance testing activities can be added by vertical standards where relevant for the product category, product function or cryptographic mechanism."}},"cryptoAgility":{"requirement":"Where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product shall provide means for addressing the affected cryptographic mechanism by one or more of the following:\n\n- a) updating the cryptographic mechanism;\n- b) using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation;\n- c) disabling the use of the affected cryptographic mechanism; or\n- d) limiting the use of the affected product functions accordingly.\n\n> EXAMPLE: Where a security mechanism uses a hybrid cryptographic construction, for example a hybrid key-encapsulation mechanism combining a classical and a post-quantum primitive, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization can be used as part of a planned migration strategy where permitted by the ACM catalogue or by the present document. However, hybridization does not, by itself, extend the recommended usage lifetime of a constituent primitive that has been deprecated.\n\n> NOTE 1: Where a hybrid cryptographic construction includes multiple cryptographic primitives, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization is not assumed to mitigate the deprecation of a constituent primitive unless the ACM catalogue or the present document classifies the hybrid construction as suitable for the corresponding product function.\n\n> NOTE 2: Crypto agility supports maintaining appropriate cryptographic protection within the intended lifetime of the product, in addition to the capability of updating cryptographic mechanisms on the product in accordance with secure update and secure communication mechanisms.\n\n> NOTE 3: Deprecation information from sources other than the ACM catalogue or the present document can be considered as input to vulnerability management or security risk assessment but does not by itself trigger the requirement in clause K.2.1.\n\n> NOTE 4: Where the product provides cryptographic capabilities for use by other products, components or layers, the mechanism required by clause K.2.1 can consist of update, configuration, disabling, deprecation or limitation capabilities usable by the integrating product, system operator or user, where applicable.\n\n> NOTE 5: The applicability condition of this requirement can express exceptions based on product characteristics, e.g. cryptographic implementation based on immutable hardware co-processor(s) or hardware-based root of trust, or long-lived silicon used in a long-lived non-updateable environment.","assessment":{"objective":"The purpose of this assessment case is to verify whether, where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product provides means to address the affected cryptographic mechanism in accordance with clause K.2.1.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall identify:\n  - a) the intended lifetime of the product;\n  - b) the cryptographic mechanisms used in the product’s default configuration;\n  - c) the related product function(s) for each cryptographic mechanism;\n  - d) the lifecycle information applicable to each cryptographic mechanism, where specified by the ACM catalogue or the present document, including any deprecation date, expiry date, migration condition or usage limitation.","activities":"The assessment shall include verification that:\n\n- a) for each cryptographic mechanism used in the product’s default configuration, the lifecycle information specified by the ACM catalogue or the present document has been identified, where such information is specified;\n- b) where the ACM catalogue or the present document specifies a deprecation date, expiry date, migration condition or usage limitation for a cryptographic mechanism, this information is reflected in the documentation;\n- c) where a deprecation date, expiry date, migration condition or usage limitation falls within the intended lifetime of the product, the product provides an applicable mechanism for updating the cryptographic mechanism, using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation, disabling the use of the affected cryptographic mechanism, or limiting the use of the affected product functions accordingly;\n- d) where another cryptographic mechanism is used, that cryptographic mechanism complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) documentation of the intended lifetime of the product;\n- b) list of cryptographic mechanisms used in the product’s default configuration;\n- c) identification of the related product function(s) for each cryptographic mechanism;\n- d) references to the ACM catalogue entry or to the provision of the present document used to determine lifecycle information, where applicable;\n- e) identification of any deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product;\n- f) description of the means provided by the product, such as update of the cryptographic mechanism, use of another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant lifecycle constraint, disabling the use of the affected cryptographic mechanism, or limitation of the use of the affected product functions.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.2.1.\n- The verdict FAIL shall be assigned otherwise."}}},"rdps":{"applicability":"The requirements in the present clause address the protection of the security properties identified for the assets in Clause R.3.1.\n\nWhere a security property is identified as relevant for a given asset in the asset tables of Clause R.3.1, the corresponding requirement family or families in the present clause shall be considered for applicability to that asset.\n\nFor _DA-RDPS-001_, the primary requirement families considered for applicability are:\n1. data authenticity of interactions;\n1. integrity of interactions; and\n1. confidentiality of exchanged data.\n\nFor _DA-RDPS-002_, the primary requirement family considered for applicability is availability.\n\nThe requirements within a given requirement family represent alternative levels of rigor and are not cumulative.\nFor each applicable requirement family, one applicable level shall be selected.\nSelection of a higher-numbered requirement within a family includes the security outcome of the lower-numbered requirement(s) in that family and does not require separate selection of those lower-numbered requirement(s).","families":[{"clause":"R.4.3.1","title":"Data authenticity of interactions received from the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-AUTH-001","REQ-RDPS-L-AUTH-002","REQ-RDPS-L-AUTH-003"]},{"clause":"R.4.3.2","title":"Integrity of interactions received from the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-INTEG-001","REQ-RDPS-L-INTEG-002","REQ-RDPS-L-INTEG-003"]},{"clause":"R.4.3.3","title":"Confidentiality of data exchanged with the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-CONF-001","REQ-RDPS-L-CONF-002","REQ-RDPS-L-CONF-003"]},{"clause":"R.4.3.4","title":"Availability","side":"local","requirementIds":["REQ-RDPS-L-AVAIL-001","REQ-RDPS-L-AVAIL-002","REQ-RDPS-L-AVAIL-003"]},{"clause":"R.4.4.1","title":"Data authenticity of interactions received from the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-AUTH-001","REQ-RDPS-R-AUTH-002","REQ-RDPS-R-AUTH-003"]},{"clause":"R.4.4.2","title":"Integrity of interactions received from the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-INTEG-001","REQ-RDPS-R-INTEG-002","REQ-RDPS-R-INTEG-003"]},{"clause":"R.4.4.3","title":"Confidentiality of data exchanged with the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-CONF-001","REQ-RDPS-R-CONF-002","REQ-RDPS-R-CONF-003"]},{"clause":"R.4.4.4","title":"Availability","side":"rdps","requirementIds":["REQ-RDPS-R-AVAIL-001","REQ-RDPS-R-AVAIL-002","REQ-RDPS-R-AVAIL-003"]}],"requirements":[{"id":"REQ-RDPS-L-AUTH-001","side":"local","family":"Data authenticity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction originates from the intended RDPS-side endpoint.","rationale":"This requirement protects against acceptance of interaction content whose claimed source or origin is not genuine.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies, before acting upon a relevant received interaction, that the interaction originates from the intended RDPS-side endpoint.","preparation":"Before starting the assessment, the following shall be identified:\n   * the RDPS-dependent product function;\n   * the interactions received from the RDPS side that can influence the behaviour, state, configuration, or security of that function;\n   * the intended RDPS-side endpoint for those interactions; and\n   * the mechanism used by the local product side to determine the origin of the received interaction.","activities":"The assessment shall include the following activities:\n   * inspect the design and configuration of the mechanism used by the local product side to determine the origin of the relevant interaction;\n   * verify that the origin of the interaction is checked before the interaction is acted upon;\n   * verify that interactions from the intended RDPS-side endpoint are accepted; and\n   * verify that interactions not originating from the intended RDPS-side endpoint are rejected or not acted upon.","verdict":"Pass:\n   * the local product side verifies the origin of the relevant interaction before acting upon it; and\n   * interactions from endpoints other than the intended RDPS-side endpoint are rejected or not acted upon.\n\n   Fail:\n   * the local product side acts upon a relevant interaction without verifying its origin; or\n   * the local product side accepts and acts upon a relevant interaction not originating from the intended RDPS-side endpoint.","evidence":"The following evidence may be used to support the assessment:\n   * design or configuration evidence describing how origin of the interaction is determined;\n   * evidence showing acceptance of interactions from the intended RDPS-side endpoint; and\n   * evidence showing rejection or non-processing of interactions from other endpoints."}},{"id":"REQ-RDPS-L-AUTH-002","side":"local","family":"Data authenticity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the data authenticity of that interaction using cryptographic endpoint authentication, an authenticated communication channel, or an equivalent cryptographic mechanism that provides assurance of the origin of the interaction.","rationale":"This requirement strengthens protection against spoofed or falsely originated interaction content by requiring cryptographic assurance of origin.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies the data authenticity of relevant received interactions using cryptographic endpoint authentication, an authenticated communication channel, or an equivalent cryptographic mechanism providing assurance of origin.","preparation":"Before starting the assessment, the following shall be identified:\n   * the RDPS-dependent product function;\n   * the relevant received interactions;\n   * the cryptographic mechanism used to provide assurance of origin; and\n   * the conditions under which the local product side accepts or rejects those interactions.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic mechanism used to provide assurance of origin;\n    * verify that the local product side checks the authenticity-protection status of the interaction before acting upon it;\n    * verify that a valid interaction protected by the intended mechanism is accepted; and\n    * verify that an interaction lacking valid cryptographic assurance of origin is rejected or not acted upon.","verdict":"Pass:\n    * the local product side uses a cryptographic mechanism providing assurance of origin for relevant received interactions;\n    * the local product side verifies that protection before acting upon the interaction; and\n    * interactions without valid assurance of origin are rejected or not acted upon.\n\n   Fail:\n    * the local product side acts upon a relevant interaction without verifying cryptographic assurance of origin; or\n    * the local product side accepts and acts upon an interaction for which the required authenticity mechanism is absent or invalid.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic authenticity mechanism;\n    * traces or logs showing successful acceptance of valid protected interactions; and\n    * traces or logs showing rejection or non-processing of interactions without valid assurance of origin."}},{"id":"REQ-RDPS-L-AUTH-003","side":"local","family":"Data authenticity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that:\n1. the cryptographic authenticity of the interaction is bound to the intended RDPS-side endpoint; and\n1. replayed or stale interactions are detected and rejected where replay or reuse could affect the secure operation of the RDPS-dependent product function.","rationale":"This requirement provides stronger protection by requiring source-bound authenticity and replay protection.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies that the cryptographic authenticity of the received interaction is bound to the intended RDPS-side endpoint and that replayed or stale interactions are detected and rejected where replay or reuse could affect secure operation.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions;\n    * the mechanism used to bind authenticity to the intended RDPS-side endpoint; and\n    * the replay or freshness protection mechanism, where applicable.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the mechanism that binds the authenticity of the interaction to the intended RDPS-side endpoint;\n    * inspect the design and configuration of the freshness, anti-replay, or equivalent mechanism used;\n    * verify that a valid interaction bound to the intended RDPS-side endpoint is accepted;\n    * verify that an interaction with valid-looking authenticity protection but not bound to the intended RDPS-side endpoint is rejected or not acted upon; and\n    * where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.","verdict":"Pass:\n    * the local product side verifies that authenticity is bound to the intended RDPS-side endpoint; and\n    * replayed or stale interactions are rejected where replay or reuse could affect secure operation.\n\n   Fail:\n    * the local product side accepts and acts upon an interaction whose cryptographic authenticity is not bound to the intended RDPS-side endpoint; or\n    * the local product side fails to detect and reject replayed or stale interactions where such protection is required.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for source binding and anti-replay/freshness controls;\n    * evidence showing acceptance of valid bound interactions; and\n    * evidence showing rejection of misbound, replayed, or stale interactions."}},{"id":"REQ-RDPS-L-INTEG-001","side":"local","family":"Integrity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction has not been modified, substituted, corrupted, or injected.","rationale":"This requirement protects against loss of integrity of received interaction content.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side checks that a relevant received interaction has not been modified, substituted, corrupted, or injected before acting upon it.","preparation":"Before starting the assessment, the following shall be identified:\n   * the RDPS-dependent product function;\n   * the relevant received interactions; and\n   * the mechanism used by the local product side to detect modification, substitution, corruption, or injection.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the integrity-checking mechanism;\n    * verify that integrity is checked before the interaction is acted upon;\n    * verify that an unmodified valid interaction is accepted; and\n    * verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon.","verdict":"Pass:\n    * the local product side checks the integrity of relevant received interactions before acting upon them; and\n    * modified, substituted, corrupted, or injected interactions are rejected or not acted upon.\n\n    Fail:\n    * the local product side acts upon a relevant interaction without verifying its integrity; or\n    * the local product side accepts and acts upon an altered, substituted, corrupted, or injected interaction.","evidence":"The following evidence may be used to support the assessment:\n    * design or configuration evidence of the integrity-checking mechanism;\n    * evidence showing acceptance of valid interactions; and\n    * evidence showing rejection or non-processing of altered or injected interactions."}},{"id":"REQ-RDPS-L-INTEG-002","side":"local","family":"Integrity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the integrity of that interaction using a cryptographic integrity-protection mechanism.","rationale":"This requirement strengthens protection against unauthorized modification or substitution of received interactions.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies the integrity of relevant received interactions using a cryptographic integrity-protection mechanism.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions; and\n    * the cryptographic integrity-protection mechanism used for those interactions.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic integrity-protection mechanism;\n    * verify that integrity verification takes place before the interaction is acted upon;\n    * verify that a valid cryptographically protected interaction is accepted; and\n    * verify that an interaction with missing or invalid integrity protection is rejected or not acted upon.","verdict":"Pass:\n    * the local product side uses cryptographic integrity protection for relevant received interactions;\n    * integrity verification is performed before the interaction is acted upon; and\n    * interactions with invalid or missing integrity protection are rejected or not acted upon.\n\n    Fail:\n    * the local product side does not use cryptographic integrity verification where required; or\n    * the local product side accepts and acts upon an interaction whose integrity protection is missing or invalid.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic integrity mechanism;\n    * evidence showing acceptance of valid protected interactions; and\n    * evidence showing rejection of interactions with invalid or missing integrity protection."}},{"id":"REQ-RDPS-L-INTEG-003","side":"local","family":"Integrity of interactions received from the RDPS side","requirement":"The local product side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction is protected by a cryptographic integrity-protection mechanism bound to the authenticated source of the interaction.","rationale":"This requirement provides stronger protection by requiring cryptographic integrity protection bound to the authenticated source.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies that the relevant received interaction is protected by a cryptographic integrity-protection mechanism bound to the authenticated source of the interaction.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions;\n    * the authenticated source of those interactions; and\n    * the mechanism used to bind integrity protection to that authenticated source.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the mechanism that binds integrity protection to the authenticated source;\n    * verify that a valid interaction whose integrity protection is correctly bound to the authenticated source is accepted;\n    * verify that an interaction with integrity protection not bound to the authenticated source is rejected or not acted upon; and\n    * verify that integrity verification and source binding checks are performed before the interaction is acted upon.","verdict":"Pass:\n    * the local product side verifies that the interaction is protected by cryptographic integrity protection bound to the authenticated source; and\n    * interactions not correctly bound to that source are rejected or not acted upon.\n\n    Fail:\n    * the local product side accepts and acts upon a relevant interaction whose integrity protection is not bound to the authenticated source; or\n    * the local product side acts upon the interaction before performing the required checks.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for integrity binding to authenticated source;\n    * evidence showing acceptance of correctly bound interactions; and\n    * evidence showing rejection of misbound interactions."}},{"id":"REQ-RDPS-L-CONF-001","side":"local","family":"Confidentiality of data exchanged with the RDPS side","requirement":"Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the local product side shall protect the confidentiality of that data during exchange with the RDPS side.","rationale":"Confidentiality is not required for every exchange.\nHowever, where disclosure of data exchanged with the RDPS side could affect the security or secure operation of the RDPS-dependent product function, confidentiality protection is required.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that, where disclosure of exchanged data could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the local product side protects the confidentiality of that data during exchange with the RDPS side.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk; and\n    * the mechanism used by the local product side to protect confidentiality during exchange.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the confidentiality-protection mechanism;\n    * verify that the identified data is protected during exchange with the RDPS side; and\n    * verify that data designated as requiring confidentiality is not exchanged in an unprotected manner.","verdict":"Pass:\n    * the local product side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk; and\n    * such data is not exchanged in an unprotected manner.\n\n    Fail:\n    * the local product side does not protect the confidentiality of exchanged data where such protection is required; or\n    * identified confidential data is exchanged without appropriate confidentiality protection.","evidence":"The following evidence may be used to support the assessment:\n    * design or configuration evidence identifying the protected data and the means of protection; and\n    * evidence showing that relevant exchanged data is protected during exchange."}},{"id":"REQ-RDPS-L-CONF-002","side":"local","family":"Confidentiality of data exchanged with the RDPS side","requirement":"Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the local product side shall protect the confidentiality of that data during exchange with the RDPS side using cryptographic confidentiality protection.","rationale":"This requirement strengthens confidentiality protection by requiring cryptographic protection of exchanged data where disclosure would create unacceptable cybersecurity risk.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side protects the confidentiality of relevant exchanged data using cryptographic confidentiality protection.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the exchanged data requiring confidentiality protection; and\n    * the cryptographic confidentiality-protection mechanism used during exchange.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic confidentiality-protection mechanism;\n    * verify that the identified exchanged data is protected by that mechanism during exchange; and\n    * verify that exchange of such data without the required cryptographic confidentiality protection is prevented.","verdict":"Pass:\n    * relevant exchanged data is protected using cryptographic confidentiality protection; and\n    * exchange without the required cryptographic protection is prevented.\n\n   Fail:\n    * the local product side exchanges relevant confidential data without cryptographic confidentiality protection; or\n    * the configured confidentiality mechanism is not effectively applied to the relevant data exchange.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic confidentiality mechanism; and\n    * evidence showing protected exchange of the relevant data."}},{"id":"REQ-RDPS-L-CONF-003","side":"local","family":"Confidentiality of data exchanged with the RDPS side","requirement":"Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the local product side shall use cryptographic confidentiality protection that is established with the intended RDPS-side endpoint and that prevents disclosure of the exchanged data to endpoints other than that intended endpoint.","rationale":"This requirement provides stronger protection by ensuring that confidential exchanged data is disclosed only to the intended peer endpoint.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side uses cryptographic confidentiality protection established with the intended RDPS-side endpoint and preventing disclosure of exchanged data to endpoints other than that intended endpoint.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the exchanged data requiring stronger confidentiality protection;\n    * the intended RDPS-side endpoint; and\n    * the cryptographic mechanism used to establish confidentiality protection with that endpoint.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic confidentiality mechanism and its association with the intended RDPS-side endpoint;\n    * verify that protected exchange is established with the intended RDPS-side endpoint;\n    * verify that the local product side does not disclose the protected data to other endpoints under the same exchange context; and\n    * verify that exchanges not established with the intended RDPS-side endpoint are rejected or do not result in disclosure of the protected data.","verdict":"Pass:\n    * confidentiality protection is established with the intended RDPS-side endpoint;\n    * protected data is disclosed only to that intended endpoint; and\n    * exchanges with other endpoints do not result in disclosure of the protected data.\n\n    Fail:\n    * the local product side discloses protected data without establishing confidentiality protection with the intended RDPS-side endpoint; or\n    * the local product side discloses the protected data to endpoints other than the intended RDPS-side endpoint.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for endpoint-associated confidentiality protection;\n    * evidence showing protected disclosure to the intended RDPS-side endpoint; and\n    * evidence showing prevention of disclosure to other endpoints."}},{"id":"REQ-RDPS-L-AVAIL-001","side":"local","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the RDPS side is necessary for the secure operation of the RDPS-dependent product function, the local product side shall:\n1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected RDPS-side interactions; and\n1. apply a defined behaviour for the RDPS-dependent product function.","rationale":"This requirement ensures that loss, delay, or degradation of RDPS-side interactions is detected and handled in a defined manner before it adversely affects the secure operation of the RDPS-dependent product function.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side detects unavailability, unacceptable delay, or intolerable degradation of required RDPS-side interactions, uses timeout or equivalent timeliness controls, and applies a defined behaviour for the RDPS-dependent product function.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required RDPS-side interactions;\n    * the acceptable timing or service conditions for those interactions; and\n    * the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the timeout, timeliness, or equivalent detection controls;\n    * verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected;\n    * verify that a defined behaviour is applied when such conditions occur; and\n    * verify that, under normal conditions, expected interactions are processed without triggering the fault-handling behaviour.","verdict":"Pass:\n    * the local product side detects the specified failure, delay, or degradation conditions;\n    * timeout or equivalent timeliness controls are used; and\n    * a defined behaviour is applied when the identified conditions occur.\n\n   Fail:\n    * the local product side does not detect the relevant failure, delay, or degradation condition; or\n    * the required defined behaviour is not applied when such a condition occurs.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for detection and timeliness controls;\n    * evidence showing detection of failure, delay, or degradation; and\n    * evidence showing application of the defined behaviour."}},{"id":"REQ-RDPS-L-AVAIL-002","side":"local","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the RDPS side is necessary for the secure operation of the RDPS-dependent product function, the local product side shall:\n1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected RDPS-side interactions;\n1. apply a defined degraded behaviour or secure state when the required RDPS-side interactions are unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits; and\n1. support recovery of the RDPS-dependent product function using locally maintained state, configuration, or other recovery information where such information is necessary to restore secure operation.","rationale":"This requirement strengthens protection by requiring controlled degraded operation or transition to a secure state, together with support for restoration of secure operation.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side applies a defined degraded behaviour or secure state when required RDPS-side interactions are unavailable, delayed, or degraded, and supports recovery of the RDPS-dependent product function where needed.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required RDPS-side interactions;\n    * the degraded behaviour or secure state defined for failure conditions; and\n    * any locally maintained state, configuration, or other recovery information required to restore secure operation.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the degraded behaviour or secure-state mechanism;\n    * inspect the design and configuration of the recovery mechanism, where applicable;\n    * verify that when required interactions become unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits, the local product side applies the defined degraded behaviour or secure state; and\n    * verify that recovery support is available and can be used to restore secure operation where such support is required.","verdict":"Pass:\n    * the local product side applies the defined degraded behaviour or secure state under the relevant failure conditions; and\n    * recovery support is available and usable where necessary to restore secure operation.\n\n    Fail:\n    * the local product side does not apply the defined degraded behaviour or secure state under the relevant failure conditions; or\n    * required recovery support is absent or ineffective.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for degraded behaviour, secure state, and recovery support; and\n    * evidence showing activation of degraded behaviour / secure state and restoration of secure operation where applicable."}},{"id":"REQ-RDPS-L-AVAIL-003","side":"local","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the RDPS side is necessary for the secure operation of the RDPS-dependent product function, the local product side shall:\n1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected RDPS-side interactions;\n1. apply a defined degraded behaviour or secure state when the required RDPS-side interactions are unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits;\n1. support recovery of the RDPS-dependent product function using locally maintained state, configuration, or other recovery information where such information is necessary to restore secure operation;\n1. support continuity of operation through failover, redundancy, or an equivalent resilience mechanism where such a mechanism is necessary.","rationale":"This requirement provides stronger protection by requiring resilience measures.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side supports higher resilience, including continuity of operation through failover, redundancy, or equivalent resilience mechanisms where necessary.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required RDPS-side interactions;\n    * the defined degraded behaviour or secure state;\n    * the recovery support; and\n    * the failover, redundancy, or equivalent resilience mechanism, where required.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the resilience mechanism used to support continuity of operation;\n    * verify that the defined degraded behaviour or secure state is applied under the relevant failure conditions;\n    * verify that recovery support is available where required;\n    * where failover, redundancy, or equivalent resilience is required, verify that continuity of operation is supported when the primary interaction path becomes unavailable, delayed, or degraded.","verdict":"Pass:\n    * the local product side supports the required resilience mechanism where necessary;\n    * defined degraded behaviour or secure state is applied under the relevant conditions; and\n    * continuity of operation is supported in accordance with the design where resilience is required.\n\n    Fail:\n    * a required resilience mechanism is absent or ineffective; or\n    * the local product side fails to support continuity of operation where such support is required.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for resilience, degraded behaviour, and recovery support; and\n    * evidence showing failover, redundancy, or equivalent continuity support where required."}},{"id":"REQ-RDPS-R-AUTH-001","side":"rdps","family":"Data authenticity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction originates from the intended local product-side endpoint.","rationale":"This requirement protects against acceptance of interaction content whose claimed source or origin is not genuine.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies, before acting upon a relevant received interaction, that the interaction originates from the intended local product-side endpoint.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the interactions received from the local product side that can influence the behaviour, state, configuration, or security of that function;\n    * the intended local product-side endpoint for those interactions; and\n    * the mechanism used by the RDPS side to determine the origin of the received interaction.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the mechanism used by the RDPS side to determine the origin of the relevant interaction;\n    * verify that the origin of the interaction is checked before the interaction is acted upon;\n    * verify that interactions from the intended local product-side endpoint are accepted; and\n    * verify that interactions not originating from the intended local product-side endpoint are rejected or not acted upon.","verdict":"Pass:\n    * the RDPS side verifies the origin of the relevant interaction before acting upon it; and\n    * interactions from endpoints other than the intended local product-side endpoint are rejected or not acted upon.\n\n   Fail:\n    * the RDPS side acts upon a relevant interaction without verifying its origin; or\n    * the RDPS side accepts and acts upon a relevant interaction not originating from the intended local product-side endpoint.","evidence":"The following evidence may be used to support the assessment:\n    * design or configuration evidence describing how origin of the interaction is determined;\n    * evidence showing acceptance of interactions from the intended local product-side endpoint; and\n    * evidence showing rejection or non-processing of interactions from other endpoints."}},{"id":"REQ-RDPS-R-AUTH-002","side":"rdps","family":"Data authenticity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the data authenticity of that interaction using cryptographic endpoint authentication, an authenticated communication channel, or an equivalent cryptographic mechanism that provides assurance of the origin of the interaction.","rationale":"This requirement strengthens protection against spoofed or falsely originated interaction content by requiring cryptographic assurance of origin.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies the data authenticity of relevant received interactions using cryptographic endpoint authentication, an authenticated communication channel, or an equivalent cryptographic mechanism providing assurance of origin.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions;\n    * the cryptographic mechanism used to provide assurance of origin; and\n    * the conditions under which the RDPS side accepts or rejects those interactions.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic mechanism used to provide assurance of origin;\n    * verify that the RDPS side checks the authenticity-protection status of the interaction before acting upon it;\n    * verify that a valid interaction protected by the intended mechanism is accepted; and\n    * verify that an interaction lacking valid cryptographic assurance of origin is rejected or not acted upon.","verdict":"Pass:\n    * the RDPS side uses a cryptographic mechanism providing assurance of origin for relevant received interactions;\n    * the RDPS side verifies that protection before acting upon the interaction; and\n    * interactions without valid assurance of origin are rejected or not acted upon.\n\n    Fail:\n    * the RDPS side acts upon a relevant interaction without verifying cryptographic assurance of origin; or\n    * the RDPS side accepts and acts upon an interaction for which the required authenticity mechanism is absent or invalid.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic authenticity mechanism;\n    * traces or logs showing successful acceptance of valid protected interactions; and\n    * traces or logs showing rejection or non-processing of interactions without valid assurance of origin."}},{"id":"REQ-RDPS-R-AUTH-003","side":"rdps","family":"Data authenticity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that:\n1. the cryptographic authenticity of the interaction is bound to the intended local product-side endpoint; and\n1. replayed or stale interactions are detected and rejected where replay or reuse could affect the secure operation of the RDPS-dependent product function.","rationale":"This requirement provides stronger protection by requiring source-bound authenticity and replay protection.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies that the cryptographic authenticity of the received interaction is bound to the intended local product-side endpoint and that replayed or stale interactions are detected and rejected where replay or reuse could affect secure operation.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions;\n    * the mechanism used to bind authenticity to the intended local product-side endpoint; and\n    * the replay or freshness protection mechanism, where applicable.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the mechanism that binds the authenticity of the interaction to the intended local product-side endpoint;\n    * inspect the design and configuration of the freshness, anti-replay, or equivalent mechanism used;\n    * verify that a valid interaction bound to the intended local product-side endpoint is accepted;\n    * verify that an interaction with valid-looking authenticity protection but not bound to the intended local product-side endpoint is rejected or not acted upon; and\n    * where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.","verdict":"Pass:\n    * the RDPS side verifies that authenticity is bound to the intended local product-side endpoint; and\n    * replayed or stale interactions are rejected where replay or reuse could affect secure operation.\n\n    Fail:\n    * the RDPS side accepts and acts upon an interaction whose cryptographic authenticity is not bound to the intended local product-side endpoint; or\n    * the RDPS side fails to detect and reject replayed or stale interactions where such protection is required.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for source binding and anti-replay/freshness controls;\n    * evidence showing acceptance of valid bound interactions; and\n    * evidence showing rejection of misbound, replayed, or stale interactions."}},{"id":"REQ-RDPS-R-INTEG-001","side":"rdps","family":"Integrity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction has not been modified, substituted, corrupted, or injected.","rationale":"This requirement protects against loss of integrity of received interaction content.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side checks that a relevant received interaction has not been modified, substituted, corrupted, or injected before acting upon it.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions; and\n    * the mechanism used by the RDPS side to detect modification, substitution, corruption, or injection.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the integrity-checking mechanism;\n    * verify that integrity is checked before the interaction is acted upon;\n    * verify that an unmodified valid interaction is accepted; and\n    * verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon.","verdict":"Pass:\n    * the RDPS side checks the integrity of relevant received interactions before acting upon them; and\n    * modified, substituted, corrupted, or injected interactions are rejected or not acted upon.\n\n    Fail:\n    * the RDPS side acts upon a relevant interaction without verifying its integrity; or\n    * the RDPS side accepts and acts upon an altered, substituted, corrupted, or injected interaction.","evidence":"The following evidence may be used to support the assessment:\n    * design or configuration evidence of the integrity-checking mechanism;\n    * evidence showing acceptance of valid interactions; and\n    * evidence showing rejection or non-processing of altered or injected interactions."}},{"id":"REQ-RDPS-R-INTEG-002","side":"rdps","family":"Integrity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the integrity of that interaction using a cryptographic integrity-protection mechanism.","rationale":"This requirement strengthens protection against unauthorized modification or substitution of received interactions.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies the integrity of relevant received interactions using a cryptographic integrity-protection mechanism.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions; and\n    * the cryptographic integrity-protection mechanism used for those interactions.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic integrity-protection mechanism;\n    * verify that integrity verification takes place before the interaction is acted upon;\n    * verify that a valid cryptographically protected interaction is accepted; and\n    * verify that an interaction with missing or invalid integrity protection is rejected or not acted upon.","verdict":"Pass:\n    * the RDPS side uses cryptographic integrity protection for relevant received interactions;\n    * integrity verification is performed before the interaction is acted upon; and\n    * interactions with invalid or missing integrity protection are rejected or not acted upon.\n\n    Fail:\n    * the RDPS side does not use cryptographic integrity verification where required; or\n    * the RDPS side accepts and acts upon an interaction whose integrity protection is missing or invalid.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic integrity mechanism;\n    * evidence showing acceptance of valid protected interactions; and\n    * evidence showing rejection of interactions with invalid or missing integrity protection."}},{"id":"REQ-RDPS-R-INTEG-003","side":"rdps","family":"Integrity of interactions received from the local product side","requirement":"The RDPS side shall verify, before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, that the interaction is protected by a cryptographic integrity-protection mechanism bound to the authenticated source of the interaction.","rationale":"This requirement provides stronger protection by requiring cryptographic integrity protection bound to the authenticated source.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies that the relevant received interaction is protected by a cryptographic integrity-protection mechanism bound to the authenticated source of the interaction.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the relevant received interactions;\n    * the authenticated source of those interactions; and\n    * the mechanism used to bind integrity protection to that authenticated source.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the mechanism that binds integrity protection to the authenticated source;\n    * verify that a valid interaction whose integrity protection is correctly bound to the authenticated source is accepted;\n    * verify that an interaction with integrity protection not bound to the authenticated source is rejected or not acted upon; and\n    * verify that integrity verification and source binding checks are performed before the interaction is acted upon.","verdict":"Pass:\n    * the RDPS side verifies that the interaction is protected by cryptographic integrity protection bound to the authenticated source; and\n    * interactions not correctly bound to that source are rejected or not acted upon.\n\n    Fail:\n    * the RDPS side accepts and acts upon a relevant interaction whose integrity protection is not bound to the authenticated source; or\n    * the RDPS side acts upon the interaction before performing the required checks.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for integrity binding to authenticated source;\n    * evidence showing acceptance of correctly bound interactions; and\n    * evidence showing rejection of misbound interactions."}},{"id":"REQ-RDPS-R-CONF-001","side":"rdps","family":"Confidentiality of data exchanged with the local product side","requirement":"Where disclosure of data exchanged with the local product side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side shall protect the confidentiality of that data during exchange with the local product side.","rationale":"This requirement ensures confidentiality where disclosure of exchanged data could affect the security or secure operation of the RDPS-dependent product function.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that, where disclosure of exchanged data could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side protects the confidentiality of that data during exchange with the local product side.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk; and\n    * the mechanism used by the RDPS side to protect confidentiality during exchange.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the confidentiality-protection mechanism;\n    * verify that the identified data is protected during exchange with the local product side; and\n    * verify that data designated as requiring confidentiality is not exchanged in an unprotected manner.","verdict":"Pass:\n    * the RDPS side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk; and\n    * such data is not exchanged in an unprotected manner.\n\n    Fail:\n    * the RDPS side does not protect the confidentiality of exchanged data where such protection is required; or\n    * identified confidential data is exchanged without appropriate confidentiality protection.","evidence":"The following evidence may be used to support the assessment:\n    * design or configuration evidence identifying the protected data and the means of protection; and\n    * evidence showing that relevant exchanged data is protected during exchange."}},{"id":"REQ-RDPS-R-CONF-002","side":"rdps","family":"Confidentiality of data exchanged with the local product side","requirement":"Where disclosure of data exchanged with the local product side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side shall protect the confidentiality of that data during exchange with the local product side using cryptographic confidentiality protection.","rationale":"This requirement strengthens confidentiality protection by requiring cryptographic protection during exchange.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side protects the confidentiality of relevant exchanged data using cryptographic confidentiality protection.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the exchanged data requiring confidentiality protection; and\n    * the cryptographic confidentiality-protection mechanism used during exchange.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic confidentiality-protection mechanism;\n    * verify that the identified exchanged data is protected by that mechanism during exchange; and\n    * verify that exchange of such data without the required cryptographic confidentiality protection is prevented.","verdict":"Pass:\n    * relevant exchanged data is protected using cryptographic confidentiality protection; and\n    * exchange without the required cryptographic protection is prevented.\n\n    Fail:\n    * the RDPS side exchanges relevant confidential data without cryptographic confidentiality protection; or\n    * the configured confidentiality mechanism is not effectively applied to the relevant data exchange.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for the cryptographic confidentiality mechanism; and\n    * evidence showing protected exchange of the relevant data."}},{"id":"REQ-RDPS-R-CONF-003","side":"rdps","family":"Confidentiality of data exchanged with the local product side","requirement":"Where disclosure of data exchanged with the local product side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side shall use cryptographic confidentiality protection that is established with the intended local product-side endpoint and that prevents disclosure of the exchanged data to endpoints other than that intended endpoint.","rationale":"This requirement provides stronger protection by ensuring that confidential exchanged data is disclosed only to the intended peer endpoint.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side uses cryptographic confidentiality protection established with the intended local product-side endpoint and preventing disclosure of exchanged data to endpoints other than that intended endpoint.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the exchanged data requiring stronger confidentiality protection;\n    * the intended local product-side endpoint; and\n    * the cryptographic mechanism used to establish confidentiality protection with that endpoint.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the cryptographic confidentiality mechanism and its association with the intended local product-side endpoint;\n    * verify that protected exchange is established with the intended local product-side endpoint;\n    * verify that the RDPS side does not disclose the protected data to other endpoints under the same exchange context; and\n    * verify that exchanges not established with the intended local product-side endpoint are rejected or do not result in disclosure of the protected data.","verdict":"Pass:\n    * confidentiality protection is established with the intended local product-side endpoint;\n    * protected data is disclosed only to that intended endpoint; and\n    * exchanges with other endpoints do not result in disclosure of the protected data.\n\n   Fail:\n    * the RDPS side discloses protected data without establishing confidentiality protection with the intended local product-side endpoint; or\n    * the RDPS side discloses the protected data to endpoints other than the intended local product-side endpoint.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for endpoint-associated confidentiality protection;\n    * evidence showing protected disclosure to the intended local product-side endpoint; and\n    * evidence showing prevention of disclosure to other endpoints."}},{"id":"REQ-RDPS-R-AVAIL-001","side":"rdps","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the local product side is necessary for the secure operation of the RDPS-dependent product function, the RDPS side shall:\n1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected local product-side interactions; and\n1. apply a defined behaviour for the RDPS-dependent product function.","rationale":"This requirement ensures that loss, delay, or degradation of local product-side interactions is detected and handled in a defined manner before it adversely affects the secure operation of the RDPS-dependent product function.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side detects unavailability, unacceptable delay, or intolerable degradation of required local product-side interactions, uses timeout or equivalent timeliness controls, and applies a defined behaviour for the RDPS-dependent product function.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required local product-side interactions;\n    * the acceptable timing or service conditions for those interactions; and\n    * the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the timeout, timeliness, or equivalent detection controls;\n    * verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected;\n    * verify that a defined behaviour is applied when such conditions occur; and\n    * verify that, under normal conditions, expected interactions are processed without triggering the fault-handling behaviour.","verdict":"Pass:\n    * the RDPS side detects the specified failure, delay, or degradation conditions;\n    * timeout or equivalent timeliness controls are used; and\n    * a defined behaviour is applied when the identified conditions occur.\n\n   Fail:\n    * the RDPS side does not detect the relevant failure, delay, or degradation condition; or\n    * the required defined behaviour is not applied when such a condition occurs.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for detection and timeliness controls;\n    * evidence showing detection of failure, delay, or degradation; and\n    * evidence showing application of the defined behaviour."}},{"id":"REQ-RDPS-R-AVAIL-002","side":"rdps","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the local product side is necessary for the secure operation of the RDPS-dependent product function, the RDPS side shall:\n1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected local product-side interactions;\n1. apply a defined degraded behaviour or secure state when the required local product-side interactions are unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits; and\n1. support recovery of the RDPS-dependent product function using maintained state, configuration, or other recovery information where such information is necessary to restore secure operation.","rationale":"This requirement strengthens protection by requiring controlled degraded operation or transition to a secure state, together with support for restoration of secure operation.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side applies a defined degraded behaviour or secure state when required local product-side interactions are unavailable, delayed, or degraded, and supports recovery of the RDPS-dependent product function where needed.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required local product-side interactions;\n    * the degraded behaviour or secure state defined for failure conditions; and\n    * any maintained state, configuration, or other recovery information required to restore secure operation.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the degraded behaviour or secure-state mechanism;\n    * inspect the design and configuration of the recovery mechanism, where applicable;\n    * verify that when required interactions become unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits, the RDPS side applies the defined degraded behaviour or secure state; and\n    * verify that recovery support is available and can be used to restore secure operation where such support is required.","verdict":"Pass:\n    * the RDPS side applies the defined degraded behaviour or secure state under the relevant failure conditions; and\n    * recovery support is available and usable where necessary to restore secure operation.\n\n   Fail:\n    * the RDPS side does not apply the defined degraded behaviour or secure state under the relevant failure conditions; or\n    * required recovery support is absent or ineffective.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for degraded behaviour, secure state, and recovery support; and\n    * evidence showing activation of degraded behaviour / secure state and restoration of secure operation where applicable."}},{"id":"REQ-RDPS-R-AVAIL-003","side":"rdps","family":"Availability","requirement":"Where the availability or timeliness of interactions received from the local product side is necessary for the secure operation of the RDPS-dependent product function, the RDPS side shall:\n1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction;\n1. use timeout or equivalent timeliness controls for expected local product-side interactions;\n1. apply a defined degraded behaviour or secure state when the required local product-side interactions are unavailable, delayed beyond the acceptable time, or degraded beyond acceptable limits;\n1. support recovery of the RDPS-dependent product function using maintained state, configuration, or other recovery information where such information is necessary to restore secure operation;\n1. support continuity of operation through failover, redundancy, or an equivalent resilience mechanism where such a mechanism is necessary; and","rationale":"This requirement provides stronger protection by requiring resilience measures.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side supports higher resilience, including continuity of operation through failover, redundancy, or equivalent resilience mechanisms where necessary.","preparation":"Before starting the assessment, the following shall be identified:\n    * the RDPS-dependent product function;\n    * the required local product-side interactions;\n    * the defined degraded behaviour or secure state;\n    * the recovery support; and\n    * the failover, redundancy, or equivalent resilience mechanism, where required.","activities":"The assessment shall include the following activities:\n    * inspect the design and configuration of the resilience mechanism used to support continuity of operation;\n    * verify that the defined degraded behaviour or secure state is applied under the relevant failure conditions;\n    * verify that recovery support is available where required;\n    * where failover, redundancy, or equivalent resilience is required, verify that continuity of operation is supported when the primary interaction path becomes unavailable, delayed, or degraded.","verdict":"Pass:\n    * the RDPS side supports the required resilience mechanism where necessary;\n    * defined degraded behaviour or secure state is applied under the relevant conditions; and\n    * continuity of operation is supported in accordance with the design where resilience is required.\n\n   Fail:\n    * a required resilience mechanism is absent or ineffective; or\n    * the RDPS side fails to support continuity of operation where such support is required.","evidence":"The following evidence may be used to support the assessment:\n    * design and configuration evidence for resilience, degraded behaviour, and recovery support; and\n    * evidence showing failover, redundancy, or equivalent continuity support where required."}}]},"threats":[{"id":"TH-UEVU","title":"Unknown exploitable vulnerabilities","description":"Attacker may use unknown exploitable vulnerabilities in the product to harm the product's 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-CACC","title":"Circumvention of access control","description":"Attacker may get unauthorized access to product assets by exploiting gaps or weaknesses in authorization or access control."},{"id":"TH-DSTP","title":"Unauthorized access to data stored via used product","description":"Attacker may get unauthorized access to confidential data stored on the product through acquisition of a used platform containing the product."},{"id":"TH-UADT","title":"Unauthorized access to data transmitted or stored","description":"Attacker may use access to the connected network to compromise the confidentiality or integrity of data transmitted by the product."},{"id":"TH-CONF","title":"Access to assets via configuration errors","description":"Attacker may use unintentional configuration errors to get unauthorized access to the product assets."},{"id":"TH-AVAI","title":"Denial of service attack on product","description":"Attacker may use network access to product to reduce availability of product functions."},{"id":"TH-DDOS","title":"Interference with other devices","description":"Attacker may use product functions to interfere with other devices or services."}],"draftGaps":["REQ-DRT-01: the Applicability clause carries no per-use-case bullets (draft text: \"null\"…); applicability taken from the topic's mapping table.","REQ-DRT-02: the Applicability clause carries no per-use-case bullets (draft text: \"This requirement applies to products with the capability for\"…); applicability taken from the topic's mapping table.","REQ-NI-02: clause 6 contains no assessment block for this requirement in this interim draft.","Annex A maps only CRA Annex I Part 1: this interim draft carries no correspondence table for Part 2 (vulnerability handling). Those obligations remain assessed through the horizontal CRA pack (II.1–II.8)."]}