ETSI EN 304 622

Cyber Resilience Act (CRA) requirements for Security Information and Event Management (SIEM) products · vertical pack 0.1.0 · 25 clause-5 requirements · Annex K · 24 Annex R requirements

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.

This is a vertical pack: a product-category standard, published in full and evaluated alongside the horizontal CRA rule pack— it supplements that pack for one Annex III category, it does not replace it. Everything below — every requirement, applicability entry, assessment block, correspondence row, threat and draft defect — is rendered from the same file the assessment engine reads. Nothing is generated at answer time, so this page cannot drift from what the product evaluates.

The same data, machine-readable, is served at /api/pack/vertical?id=en-304-622 — fetch it, keep a copy, and diff it when the draft moves. Because the standard is a moving draft, the source card pins exactly which text this pack was built from, and the draft gaps card records the defects we found in that text rather than papering over them.

On this page: source & license · how it attaches · requirement index · full text · Annex K · Annex R · CRA correspondence · threats · draft gaps · how it's built

Source, license and attribution

  • Source: https://labs.etsi.org/rep/stan4cra/en-304-622 (the ETSI Labs draft repository), commit cf3cc71e5ae0, retrieved 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.

To be plain about what that means: the normative requirement and assessment text on this page is reproduced verbatim from the interim draft under the license above, with the required copyright notice, conditions and disclaimer preserved in full below. The draft is a consultation document, not an ETSI deliverable — approved versions of ETSI standards are available only from the ETSI Documentation Service, and nothing reproduced here confers any presumption of conformity.

Full license text
Copyright 2025 ETSI Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

How this pack attaches

The pack applies to products classified under the CRA Annex III item “Security information and event management (SIEM) systems” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III SIEM item, or manually. The horizontal CRA pack keeps evaluating the product either way; this pack adds the category-specific requirements on top.

Scope (the draft’s own)

The present document specifies technical requirements and corresponding assessment criteria for Security Incident Event Management related to cybersecurity. The products with digital elements in scope, thereafter “SIEM” or “SIEM systems”: - are specified within the “technical description” of the “category of product” number 7 by the Commission Implementing Regulation (EU) 2025/2392 [i.2] as: > 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. - are only covered within the product context described in clause 4. The 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. SIEM 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].

Applicability (the draft’s own)

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. The requirements in this section are unconditionally applicable, unless specifically indicated with a conditional phrasing, or the functionality is implemented with RDPS.
5.1.2 Applicability of Annex K Where 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.
5.1.3 Applicability of Annex R Where 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. NOTE: Annex R specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.

The 4 use cases

Applicability is declared per use case: the draft defines 4 product contexts, and each clause-5 requirement states, per use case, whether it is required. The index below renders every column; enabling the pack on an assessment means choosing one of these.

Research SIEMUC-1-RESEARCH
* Goal: Provide minimum functionality for research or training * Description: * Examples: Simple SIEM for a collection of containers used for research or training * Function: Monitor simulated elements * Network connectivity: Isolated private network * Sensitivity of product functions: Low * Number of monitored assets: Low * User administration skill: High
Home SIEMUC-2-HOME
* Goal: Monitor a small number of home devices * Description: * Examples: Homelab SIEM * Function: Monitor home devices for anomalies * Network connectivity: Filtered private network * Sensitivity of product functions: Medium * Number of monitored assets: Low * User administration skill: High
Fleet monitoringUC-3-FLEET
* Goal: Monitor a homogenous fleet of devices in a controlled area * Description: * Examples: Servers in a data centre, phones in a test lab * Function: Monitor health and network traffic within a facility * Network connectivity: Filtered private * Sensitivity of product functions: High * Number of monitored assets: High * User administration skill: High
IoT monitoringUC-4-IOT
* Goal: Monitor large fleet of IoT devices * Description: * Examples: SIEM for network-connected washing machines * Function: Monitor a large fleet of appliances * Network connectivity: Public network * Sensitivity of product functions: Medium * Number of monitored assets: High * User administration skill: Medium

Requirement index

Every requirement in one place: the 25 clause-5 requirements with their per-use-case applicability, the 2 Annex K entries, and the 24 Annex R (remote data processing) requirements. Ids link to the full verbatim text below; each row is addressable so a review can cite specific rows.

IdRequirement (first line)UC-1UC-2UC-3UC-4
5.2 — Appropriate level of cybersecurity
REQ-ALC-01All cybersecurity-relevant parts of the product shall implement methods to validate untrusted inputs and mitigate the effects thereof.—●●●
REQ-ALC-02The product shall record all system time drift corrections as monitoring events.——●●
5.3 — No known exploitable vulnerabilities
REQ-KEV-011. REQ-KEV-01-1 The product shall have no known exploitable vulnerabilities discovered during testing, or—●●●
5.4 — Secure by default configuration
No requirement of its own in this draft — addressed by REQ-ASM-01, REQ-CON-01, REQ-CON-03, REQ-INT-01, REQ-INT-03 under other clauses.
5.5 — Security updates
REQ-SU-01The product shall support securely updating the product via the operational environment.—●●●
5.6 — Authentication and access control
REQ-AAC-01The product shall support authentication and access control to the product via the operational environment.—●●●
5.7 — Confidentiality protection
REQ-CON-01The product shall support confidentiality protection of the ingested data via the operational environment.—●●●
REQ-CON-02The product shall distinguish between confidentiality-protected and non-confidentiality protected channels between the server and monitored elements in a user-visible way.——●●
REQ-CON-03The product shall cryptographically protect the confidentiality of stored secrets.—●●●
5.8 — Integrity protection
REQ-INT-01The product shall support integrity protection of the ingested data via the operational environment.—●●●
REQ-INT-02The product shall distinguish between integrity-protected and non-integrity protected channels between the server and monitored elements in a user-visible way.——●●
REQ-INT-03The product shall support integrity protection of stored secrets via the operational environment.—●●●
5.9 — Data minimisation
REQ-DM-01The product shall minimize the data processing by the product.—●●●
5.10 — Availability protection
REQ-AP-01The product shall support availability protection via the operational environment.—●●●
REQ-AP-02The product shall record log events or emit alerts when it detects ingest data being dropped.——●●
REQ-AP-03The product shall mitigate any impact on product availability caused by monitored elements.——●●
REQ-AP-04The 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.——●●
5.11 — Non-interference
REQ-NI-01The 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.—●●●
REQ-NI-02The product shall minimize the impact to other products or services sharing data storage with the product.——●●
5.12 — Attack surface minimisation
REQ-ASM-01Exposure of interfaces on the product shall be minimised in its secure-by-default configuration.—●●●
5.13 — Exploit mitigation
REQ-EM-01The product shall detect and report loss or degradation of monitoring data from monitored elements.——●●
The draft also points this clause at REQ-ALC-01, REQ-ALC-02, REQ-MON-01, REQ-MON-02, REQ-MON-03, REQ-AP-01, REQ-AP-02, REQ-AP-03 under other clauses.
5.14 — Monitoring
REQ-MON-01The product shall record cyber-security relevant events.—●●●
REQ-MON-02The product shall protect internal log data from unauthorized access.—●●●
REQ-MON-03The product shall not modify internal log data in contravention to the product's log retention policy, if any.——●●
5.15 — Factory reset and data portability
REQ-DRT-01The product shall provide a function to remove all user data and settings, and provide a function to restore to its secure-by-default state.—●●●
REQ-DRT-02The product shall support secure read of all user data and settings from the product via the operational environment.—●●●
Annex K — cryptography
REQ-K-CRYPTO-CONFCryptographic mechanisms used in the product's default configuration conform to the ACM catalogue as assessed under clause K.1.2 (ACM-listed, ACM-extended per K.3, or interoperability-based per K.4). The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1.Conditional — see text
REQ-K-CRYPTO-AGILITYWhere 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:Conditional — see text

● = required for that use case · — = not required. Use cases: UC-1-RESEARCH Research SIEM · UC-2-HOME Home SIEM · UC-3-FLEET Fleet monitoring · UC-4-IOT IoT monitoring. Annex K entries are conditional on the product’s use of cryptographic mechanisms, not on the use case.

Annex R — remote data processing (RDPS)

These apply only where the product relies on an RDPS. Within each family the numbered requirements are alternative levels of rigor, not cumulative — one level is selected per applicable family, and a higher level includes the outcome of the lower ones. The draft’s full selection rule is in the Annex R card.

IdSideLevelRequirement (first line)
R.4.3.1 — Data authenticity of interactions received from the RDPS side
REQ-RDPS-L-AUTH-001local product side1 of 3The 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.
REQ-RDPS-L-AUTH-002local product side2 of 3The 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.
REQ-RDPS-L-AUTH-003local product side3 of 3The 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:
R.4.3.2 — Integrity of interactions received from the RDPS side
REQ-RDPS-L-INTEG-001local product side1 of 3The 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.
REQ-RDPS-L-INTEG-002local product side2 of 3The 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.
REQ-RDPS-L-INTEG-003local product side3 of 3The 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.
R.4.3.3 — Confidentiality of data exchanged with the RDPS side
REQ-RDPS-L-CONF-001local product side1 of 3Where 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.
REQ-RDPS-L-CONF-002local product side2 of 3Where 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.
REQ-RDPS-L-CONF-003local product side3 of 3Where 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.
R.4.3.4 — Availability
REQ-RDPS-L-AVAIL-001local product side1 of 3Where 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:
REQ-RDPS-L-AVAIL-002local product side2 of 3Where 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:
REQ-RDPS-L-AVAIL-003local product side3 of 3Where 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:
R.4.4.1 — Data authenticity of interactions received from the local product side
REQ-RDPS-R-AUTH-001RDPS side1 of 3The 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.
REQ-RDPS-R-AUTH-002RDPS side2 of 3The 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.
REQ-RDPS-R-AUTH-003RDPS side3 of 3The 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:
R.4.4.2 — Integrity of interactions received from the local product side
REQ-RDPS-R-INTEG-001RDPS side1 of 3The 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.
REQ-RDPS-R-INTEG-002RDPS side2 of 3The 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.
REQ-RDPS-R-INTEG-003RDPS side3 of 3The 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.
R.4.4.3 — Confidentiality of data exchanged with the local product side
REQ-RDPS-R-CONF-001RDPS side1 of 3Where 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.
REQ-RDPS-R-CONF-002RDPS side2 of 3Where 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.
REQ-RDPS-R-CONF-003RDPS side3 of 3Where 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.
R.4.4.4 — Availability
REQ-RDPS-R-AVAIL-001RDPS side1 of 3Where 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:
REQ-RDPS-R-AVAIL-002RDPS side2 of 3Where 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:
REQ-RDPS-R-AVAIL-003RDPS side3 of 3Where 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:

5.2 — Appropriate level of cybersecurity

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (1). In 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.
REQ-ALC-01 — All cybersecurity-relevant parts of the product shall implement methods to validate untrusted i…Clause 5.2

Requirement (verbatim from the interim draft)

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

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: * calculation of memory accesses: length, index, hash table lookup values, packet reassembly * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations * incrementing or decrementing of internal counters: packet counters, event counters * creating or populating internal data structures: parameters for creating an array of packet descriptors For 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: * the maximum valid value or length of input for that field * the minimum valid value or length of input for that field * the next value/length of input above the minimum valid value * the next value/length of input below the minimum valid value * the next value/length of input below the maximum valid value * the next value/length of input above the maximum valid value * the maximum possible value or length of input for that field * the minimum possible value or length of input for that field * the next value/length of input above the minimum possible value * the next value/length of input below the maximum possible value * a representative selection of other valid and invalid values or input lengths for that field * values that could cause overflow or underflow of internal counters * values that are inconsistent with other values in the input Identify 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. Otherwise FAIL

Evidence the standard asks for

* Description of identified fields of untrusted input * Analysis of sources of untrusted input for identified inputs * Sufficiency analysis of analysis of untrusted sources of input * Description of test inputs and acceptable behaviors * Logs of testing inputs and recording behavior * 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. 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. Examples of each of the types of input: * calculation of memory accesses: length, index, hash table lookup values, packet reassembly * allocation of product resources: buffer length, number of packet descriptors, buffers for reassembly of fragmented packets, CPU-intensive cryptographic operations * incrementing or decrementing of internal counters: packet counters, event counters * creating or populating internal data structures: parameters for creating an array of packet descriptors The 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. Secure 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. Acceptable behaviors might include: * Rejection of input and returning an error * Silent discard of input * Correction of input * Dropping client data and incrementing an error counter * Emitting a error event * Emitting a notification when a counter rolls over * Crashing and restarting * Terminating a thread
REQ-ALC-02 — The product shall record all system time drift corrections as monitoring events.Clause 5.2

Requirement (verbatim from the interim draft)

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

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; 2. 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: 1. the product detects the drift, and 2. the product creates a notification about the event. Otherwise FAIL

Evidence the standard asks for

* System notification from the logs.

5.3 — No known exploitable vulnerabilities

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (a).
REQ-KEV-01 — 1. REQ-KEV-01-1 The product shall have no known exploitable vulnerabilities discovered duri…Clause 5.3

Requirement (verbatim from the interim draft)

1. REQ-KEV-01-1 The product shall have no known exploitable vulnerabilities discovered during testing, or 2. 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 3. 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

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. > NOTE: An exploitable vulnerability's transition from “unknown” to “known” may be by its publication to the EU Vulnerability Database i.9, an industry-specific vulnerability database, or direct notification to the manufacturer via its own vulnerability reporting process. * UC-1-RESEARCH: not required * UC-2-HOME: required * UC-3-FLEET: required * UC-4-IOT: required

Objective

Prevent exploitation of known exploitable vulnerabilities.

Preparation

Using the product's SBOM and relevant publicly accessible vulnerability databases (e.g. GCVE, EUVD), 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: * No vulnerabilities found, or * all reported vulnerabilities satisfy either the elapsed time since discovery or mitigation requirement. Otherwise FAIL

Evidence the standard asks for

* Documented vulnerability handling policy * Product SBOM * List of testing tools used or manual test plan * Test reports/scan results * Correlation of discovered vulnerabilities with: * documentation of mitigation, or * elapsed time since discovery of vulnerability.

5.4 — Secure by default configuration

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (b).

This draft defines no requirement of its own under this clause; it records the clause as addressed by REQ-ASM-01, REQ-CON-01, REQ-CON-03, REQ-INT-01, REQ-INT-03.

5.5 — Security updates

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (c).
REQ-SU-01 — The product shall support securely updating the product via the operational environment.Clause 5.5

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Logs of reading original and updated version of product * Security update file(s) * 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.

5.6 — Authentication and access control

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (d).
REQ-AAC-01 — The product shall support authentication and access control to the product via the operational…Clause 5.6

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Descriptions of types of product assets requiring authorization or access control * Records of configuration, input, and/or preparation for each test * Logs of access attempts and their results

5.7 — Confidentiality protection

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (e).
REQ-CON-01 — The product shall support confidentiality protection of the ingested data via the operational e…Clause 5.7

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
REQ-CON-02 — The product shall distinguish between confidentiality-protected and non-confidentiality protect…Clause 5.7

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * 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: * addition of a monitored element * display of monitoring data * display of processed data * in an alert * in a report * in a log message
REQ-CON-03 — The product shall cryptographically protect the confidentiality of stored secrets.Clause 5.7

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement.

5.8 — Integrity protection

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (f).
REQ-INT-01 — The product shall support integrity protection of the ingested data via the operational environ…Clause 5.8

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
REQ-INT-02 — The product shall distinguish between integrity-protected and non-integrity protected channels…Clause 5.8

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * 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: * addition of a monitored element * display of monitoring data * display of processed data * in an alert * in a report * in a log message
REQ-INT-03 — The product shall support integrity protection of stored secrets via the operational environmen…Clause 5.8

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

5.9 — Data minimisation

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (g).
REQ-DM-01 — The product shall minimize the data processing by the product.Clause 5.9

Requirement (verbatim from the interim draft)

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

Objective

Minimise data processed by the product.

Preparation

Determine all data processing done by the product, using as necessary: * product technical documentation * product functions * product interfaces * data transmitted by the product * data stored by the product * product binaries * source code * 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. Otherwise FAIL

Evidence the standard asks for

* Product information used to determine what data processing the product does * 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: * Collected log data * Metrics * Internal events * Performance data * Debug logs

5.10 — Availability protection

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (h).
REQ-AP-01 — The product shall support availability protection via the operational environment.Clause 5.10

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Documentation * Analysis of documentation * Documentation of intended purpose
REQ-AP-02 — The product shall record log events or emit alerts when it detects ingest data being dropped.Clause 5.10

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Description of test setup * Logs from product with dropped ingest data annotated
REQ-AP-03 — The product shall mitigate any impact on product availability caused by monitored elements.Clause 5.10

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Description of test setup * Logs from product * Analysis of proportion of data ingested from well-behaved monitored element * Analysis of events recording data dropped from well-behaved monitored element * Sufficiency analysis of analysis of proportion of data ingested * Sufficiency analysis of analysis of events recording data dropped
REQ-AP-04 — The product shall limit and fairly allocate memory usage triggered by untrusted input to mainta…Clause 5.10

Requirement (verbatim from the interim draft)

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. > 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

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, 1. send the input to the product, 2. 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: For each set of inputs, * the product functions, and * the platform functions remain acceptably available. Otherwise FAIL

Evidence the standard asks for

* Set of inputs * Logs of measurements * Explanation of availability metrics

5.11 — Non-interference

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (i).
REQ-NI-01 — The product shall minimise the data originating from the product itself that is transmitted to…Clause 5.11

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Description of identified interfaces * Description of methods for identifying interfaces * Sufficiency analaysis of methods for identifying interfaces * Description of identified inputs * Packet captures or other appropriate logs of the data transmitted * Sufficiency analysis of analysis of amount of data in response
REQ-NI-02 — The product shall minimize the impact to other products or services sharing data storage with t…Clause 5.11

Requirement (verbatim from the interim draft)

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

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

5.12 — Attack surface minimisation

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (j).
REQ-ASM-01 — Exposure of interfaces on the product shall be minimised in its secure-by-default configuration.Clause 5.12

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Documentation of and rationale for search process for interfaces * Logs of searches for interfaces * Description of identified interfaces * Sufficiency analysis of rationale for interface search process * Analysis of necessity of and alternatives to each identified interface * Sufficiency analysis of necessity analysis for identified exposed interfaces

Guidance

See Clause [6.1.2] "Guidance for identifying interfaces or data processing."

5.13 — Exploit mitigation

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (k).
REQ-EM-01 — The product shall detect and report loss or degradation of monitoring data from monitored eleme…Clause 5.13

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Logs of the monitored element's ingest data * Logs of product notifications or alerts

The draft also points this clause at REQ-ALC-01, REQ-ALC-02, REQ-MON-01, REQ-MON-02, REQ-MON-03, REQ-AP-01, REQ-AP-02, REQ-AP-03 under other clauses.

5.14 — Monitoring

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (l).
REQ-MON-01 — The product shall record cyber-security relevant events.Clause 5.14

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Method of triggering events * Logs of triggering events and generated log messages * Log messages with annotations * Sufficiency analysis of annotated log messages
REQ-MON-02 — The product shall protect internal log data from unauthorized access.Clause 5.14

Requirement (verbatim from the interim draft)

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

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;
REQ-MON-03 — The product shall not modify internal log data in contravention to the product's log retention…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall not modify internal log data in contravention to the product's log retention policy, if any.

Applicability

This requirement applies to products with a product log retention policy. * UC-1-RESEARCH: not required * UC-2-HOME: not required * UC-3-FLEET: required * UC-4-IOT: required

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. Otherwise FAIL

Evidence the standard asks for

* Test reports showing the steps performed and results obtained; * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour; * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;

5.15 — Factory reset and data portability

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (m).
REQ-DRT-01 — The product shall provide a function to remove all user data and settings, and provide a functi…Clause 5.15

Requirement (verbatim from the interim draft)

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

null

The draft’s own applicability clause for this requirement is defective; applicability is taken from the topic’s mapping table. Recorded in the draft gaps.

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: 1. record the value of the setting in the secure-by-default configuration of the product 2. write an instance of the data or setting stored on the product that is different from the default Once 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: * All user data and settings tested have been deleted, and * All settings data and settings tested are restored to a secure-by-default state. Otherwise FAIL

Evidence the standard asks for

* Description of each type of user data or setting written * For each type, record of original value, written value, and value after deletion and reset to secure-by-default method * Comparison and analysis of different values * 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.
REQ-DRT-02 — The product shall support secure read of all user data and settings from the product via the op…Clause 5.15

Requirement (verbatim from the interim draft)

The product shall support secure read of all user data and settings from the product via the operational environment.

Applicability

This requirement applies to products with the capability for the user to write data and/or settings that fall within the following use cases: null

The draft’s own applicability clause for this requirement is defective; applicability is taken from the topic’s mapping table. Recorded in the draft gaps.

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: 1. record the value of the setting in the secure-by-default configuration of the product 2. write an instance of the data or setting stored on the product that is different from the default Once 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. Otherwise FAIL

Evidence the standard asks for

* Description of each type of user data or setting written * For each type, record of original value, written value, and read value * Comparison and analysis of values * Sufficiency analysis of comparison

Annex K — cryptography

Annex K applies where the product relies on cryptographic mechanisms (clause 5.1.2, quoted in how this pack attaches). The two entries below are how this pack makes the annex answerable: their REQ-K-*ids are Vandorisk handles for the clauses named in the text, not ids the draft itself defines — everything inside them is the draft’s text.

The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1. For 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.
REQ-K-CRYPTO-CONF — Cryptographic mechanisms used in the product's default configuration conform to the ACM catalog…Annex K

Requirement (verbatim from the interim draft)

Cryptographic mechanisms used in the product's default configuration conform to the ACM catalogue as assessed under clause K.1.2 (ACM-listed, ACM-extended per K.3, or interoperability-based per K.4). The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1. For 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.

Applicability

Per clause 5.1.2, Annex K applies as the product uses cryptographic mechanisms. NOTE: this interim draft references acceptance criteria in clause K.1.1, which the draft does not yet contain.

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. - 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: - a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry; - b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable; - 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.

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). - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 1); - c) references to the relevant ACM entries; - d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable; - e) relevant lifecycle information from the ACM catalogue, where applicable.
REQ-K-CRYPTO-AGILITY — Where the product’s default configuration uses a cryptographic mechanism for which the ACM cata…Annex K

Requirement (verbatim from the interim draft)

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: - a) updating the cryptographic mechanism; - 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; - c) disabling the use of the affected cryptographic mechanism; or - d) limiting the use of the affected product functions accordingly. > 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. > 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. > 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. > 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. > 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. > 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.

Applicability

Per clause K.2.1: applies where a used cryptographic mechanism has a deprecation/expiry/migration condition within the product's intended lifetime.

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. - The documentation shall identify: - a) the intended lifetime of the product; - b) the cryptographic mechanisms used in the product’s default configuration; - c) the related product function(s) for each cryptographic mechanism; - 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: - 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; - 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; - 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; - 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.

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. - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) documentation of the intended lifetime of the product; - b) list of cryptographic mechanisms used in the product’s default configuration; - c) identification of the related product function(s) for each cryptographic mechanism; - d) references to the ACM catalogue entry or to the provision of the present document used to determine lifecycle information, where applicable; - e) identification of any deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product; - 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.

The assessment cases of clause K.1.2

The draft assesses default-configuration cryptography through 3 cases. All of them, verbatim:

acm-listedK.1.2 assessment case

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. - 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: - a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry; - b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable; - 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.

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). - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 1); - c) references to the relevant ACM entries; - d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable; - e) relevant lifecycle information from the ACM catalogue, where applicable.
acm-extendedK.1.2 assessment case

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. - 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: - a) the relevant entry in clause K.3.2; or - 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: - 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; - 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; - 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; - 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; - 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; - f) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.

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). - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 2); - c) reference to the relevant entry in clause K.3.2, where the mechanism is listed in clause K.3.2; - 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; - e) identification of the related product function using the cryptographic mechanism and the use case where applicable; - f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable; - 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.
interoperabilityK.1.2 assessment case

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. - 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: - 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; - b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in clause K.4.2; - 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; - 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; - 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; - 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; - g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.

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). - The verdict FAIL shall be assigned otherwise. > 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. > 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.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 3); - c) reference to the relevant entry in clause K.4.2; - d) identification of the related product function using the cryptographic mechanism and the use case where applicable; - e) identification of the external specification or external requirement requiring use of the cryptographic mechanism; - f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable; - g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.4.2.

Annex R — remote data processing

Annex R applies where the product relies on a remote data processing solution (quoted in how this pack attaches). It covers the product-facing RDPS boundary from both sides. The draft’s own applicability and level-selection rule:

The requirements in the present clause address the protection of the security properties identified for the assets in Clause R.3.1. Where 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. For _DA-RDPS-001_, the primary requirement families considered for applicability are: 1. data authenticity of interactions; 1. integrity of interactions; and 1. confidentiality of exchanged data. For _DA-RDPS-002_, the primary requirement family considered for applicability is availability. The requirements within a given requirement family represent alternative levels of rigor and are not cumulative. For each applicable requirement family, one applicable level shall be selected. Selection 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).

R.4.3.1 — Data authenticity of interactions received from the RDPS sidelocal product side

REQ-RDPS-L-AUTH-001 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.1 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement protects against acceptance of interaction content whose claimed source or origin is not genuine.

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: * the RDPS-dependent product function; * the interactions received from the RDPS side that can influence the behaviour, state, configuration, or security of that function; * the intended RDPS-side endpoint for those interactions; and * the mechanism used by the local product side to determine the origin of the received interaction.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism used by the local product side to determine the origin of the relevant interaction; * verify that the origin of the interaction is checked before the interaction is acted upon; * verify that interactions from the intended RDPS-side endpoint are accepted; and * verify that interactions not originating from the intended RDPS-side endpoint are rejected or not acted upon.

Verdict

Pass: * the local product side verifies the origin of the relevant interaction before acting upon it; and * interactions from endpoints other than the intended RDPS-side endpoint are rejected or not acted upon. Fail: * the local product side acts upon a relevant interaction without verifying its origin; or * the local product side accepts and acts upon a relevant interaction not originating from the intended RDPS-side endpoint.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence describing how origin of the interaction is determined; * evidence showing acceptance of interactions from the intended RDPS-side endpoint; and * evidence showing rejection or non-processing of interactions from other endpoints.
REQ-RDPS-L-AUTH-002 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.1 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens protection against spoofed or falsely originated interaction content by requiring cryptographic assurance of origin.

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: * the RDPS-dependent product function; * the relevant received interactions; * the cryptographic mechanism used to provide assurance of origin; and * the conditions under which the local product side accepts or rejects those interactions.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic mechanism used to provide assurance of origin; * verify that the local product side checks the authenticity-protection status of the interaction before acting upon it; * verify that a valid interaction protected by the intended mechanism is accepted; and * verify that an interaction lacking valid cryptographic assurance of origin is rejected or not acted upon.

Verdict

Pass: * the local product side uses a cryptographic mechanism providing assurance of origin for relevant received interactions; * the local product side verifies that protection before acting upon the interaction; and * interactions without valid assurance of origin are rejected or not acted upon. Fail: * the local product side acts upon a relevant interaction without verifying cryptographic assurance of origin; or * the local product side accepts and acts upon an interaction for which the required authenticity mechanism is absent or invalid.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic authenticity mechanism; * traces or logs showing successful acceptance of valid protected interactions; and * traces or logs showing rejection or non-processing of interactions without valid assurance of origin.
REQ-RDPS-L-AUTH-003 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.1 · level 3 of 3

Requirement (verbatim from the interim draft)

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: 1. the cryptographic authenticity of the interaction is bound to the intended RDPS-side endpoint; and 1. replayed or stale interactions are detected and rejected where replay or reuse could affect the secure operation of the RDPS-dependent product function.

Rationale (the draft’s own)

This requirement provides stronger protection by requiring source-bound authenticity and replay protection.

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: * the RDPS-dependent product function; * the relevant received interactions; * the mechanism used to bind authenticity to the intended RDPS-side endpoint; and * the replay or freshness protection mechanism, where applicable.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism that binds the authenticity of the interaction to the intended RDPS-side endpoint; * inspect the design and configuration of the freshness, anti-replay, or equivalent mechanism used; * verify that a valid interaction bound to the intended RDPS-side endpoint is accepted; * 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 * where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.

Verdict

Pass: * the local product side verifies that authenticity is bound to the intended RDPS-side endpoint; and * replayed or stale interactions are rejected where replay or reuse could affect secure operation. Fail: * the local product side accepts and acts upon an interaction whose cryptographic authenticity is not bound to the intended RDPS-side endpoint; or * the local product side fails to detect and reject replayed or stale interactions where such protection is required.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for source binding and anti-replay/freshness controls; * evidence showing acceptance of valid bound interactions; and * evidence showing rejection of misbound, replayed, or stale interactions.

R.4.3.2 — Integrity of interactions received from the RDPS sidelocal product side

REQ-RDPS-L-INTEG-001 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.2 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement protects against loss of integrity of received interaction content.

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: * the RDPS-dependent product function; * the relevant received interactions; and * the mechanism used by the local product side to detect modification, substitution, corruption, or injection.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the integrity-checking mechanism; * verify that integrity is checked before the interaction is acted upon; * verify that an unmodified valid interaction is accepted; and * verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon.

Verdict

Pass: * the local product side checks the integrity of relevant received interactions before acting upon them; and * modified, substituted, corrupted, or injected interactions are rejected or not acted upon. Fail: * the local product side acts upon a relevant interaction without verifying its integrity; or * the local product side accepts and acts upon an altered, substituted, corrupted, or injected interaction.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence of the integrity-checking mechanism; * evidence showing acceptance of valid interactions; and * evidence showing rejection or non-processing of altered or injected interactions.
REQ-RDPS-L-INTEG-002 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.2 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens protection against unauthorized modification or substitution of received interactions.

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: * the RDPS-dependent product function; * the relevant received interactions; and * the cryptographic integrity-protection mechanism used for those interactions.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic integrity-protection mechanism; * verify that integrity verification takes place before the interaction is acted upon; * verify that a valid cryptographically protected interaction is accepted; and * verify that an interaction with missing or invalid integrity protection is rejected or not acted upon.

Verdict

Pass: * the local product side uses cryptographic integrity protection for relevant received interactions; * integrity verification is performed before the interaction is acted upon; and * interactions with invalid or missing integrity protection are rejected or not acted upon. Fail: * the local product side does not use cryptographic integrity verification where required; or * the local product side accepts and acts upon an interaction whose integrity protection is missing or invalid.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic integrity mechanism; * evidence showing acceptance of valid protected interactions; and * evidence showing rejection of interactions with invalid or missing integrity protection.
REQ-RDPS-L-INTEG-003 — The local product side shall verify, before acting upon a received interaction that can influen…R.4.3.2 · level 3 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement provides stronger protection by requiring cryptographic integrity protection bound to the authenticated source.

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: * the RDPS-dependent product function; * the relevant received interactions; * the authenticated source of those interactions; and * the mechanism used to bind integrity protection to that authenticated source.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism that binds integrity protection to the authenticated source; * verify that a valid interaction whose integrity protection is correctly bound to the authenticated source is accepted; * verify that an interaction with integrity protection not bound to the authenticated source is rejected or not acted upon; and * verify that integrity verification and source binding checks are performed before the interaction is acted upon.

Verdict

Pass: * the local product side verifies that the interaction is protected by cryptographic integrity protection bound to the authenticated source; and * interactions not correctly bound to that source are rejected or not acted upon. Fail: * the local product side accepts and acts upon a relevant interaction whose integrity protection is not bound to the authenticated source; or * the local product side acts upon the interaction before performing the required checks.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for integrity binding to authenticated source; * evidence showing acceptance of correctly bound interactions; and * evidence showing rejection of misbound interactions.

R.4.3.3 — Confidentiality of data exchanged with the RDPS sidelocal product side

REQ-RDPS-L-CONF-001 — Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity…R.4.3.3 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

Confidentiality is not required for every exchange. However, 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.

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: * the RDPS-dependent product function; * the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk; and * the mechanism used by the local product side to protect confidentiality during exchange.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the confidentiality-protection mechanism; * verify that the identified data is protected during exchange with the RDPS side; and * verify that data designated as requiring confidentiality is not exchanged in an unprotected manner.

Verdict

Pass: * the local product side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk; and * such data is not exchanged in an unprotected manner. Fail: * the local product side does not protect the confidentiality of exchanged data where such protection is required; or * identified confidential data is exchanged without appropriate confidentiality protection.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence identifying the protected data and the means of protection; and * evidence showing that relevant exchanged data is protected during exchange.
REQ-RDPS-L-CONF-002 — Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity…R.4.3.3 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens confidentiality protection by requiring cryptographic protection of exchanged data where disclosure would create unacceptable cybersecurity risk.

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: * the RDPS-dependent product function; * the exchanged data requiring confidentiality protection; and * the cryptographic confidentiality-protection mechanism used during exchange.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic confidentiality-protection mechanism; * verify that the identified exchanged data is protected by that mechanism during exchange; and * verify that exchange of such data without the required cryptographic confidentiality protection is prevented.

Verdict

Pass: * relevant exchanged data is protected using cryptographic confidentiality protection; and * exchange without the required cryptographic protection is prevented. Fail: * the local product side exchanges relevant confidential data without cryptographic confidentiality protection; or * the configured confidentiality mechanism is not effectively applied to the relevant data exchange.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic confidentiality mechanism; and * evidence showing protected exchange of the relevant data.
REQ-RDPS-L-CONF-003 — Where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity…R.4.3.3 · level 3 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement provides stronger protection by ensuring that confidential exchanged data is disclosed only to the intended peer endpoint.

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: * the RDPS-dependent product function; * the exchanged data requiring stronger confidentiality protection; * the intended RDPS-side endpoint; and * the cryptographic mechanism used to establish confidentiality protection with that endpoint.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic confidentiality mechanism and its association with the intended RDPS-side endpoint; * verify that protected exchange is established with the intended RDPS-side endpoint; * verify that the local product side does not disclose the protected data to other endpoints under the same exchange context; and * 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: * confidentiality protection is established with the intended RDPS-side endpoint; * protected data is disclosed only to that intended endpoint; and * exchanges with other endpoints do not result in disclosure of the protected data. Fail: * the local product side discloses protected data without establishing confidentiality protection with the intended RDPS-side endpoint; or * the local product side discloses the protected data to endpoints other than the intended RDPS-side endpoint.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for endpoint-associated confidentiality protection; * evidence showing protected disclosure to the intended RDPS-side endpoint; and * evidence showing prevention of disclosure to other endpoints.

R.4.3.4 — Availabilitylocal product side

REQ-RDPS-L-AVAIL-001 — Where the availability or timeliness of interactions received from the RDPS side is necessary f…R.4.3.4 · level 1 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected RDPS-side interactions; and 1. apply a defined behaviour for the RDPS-dependent product function.

Rationale (the draft’s own)

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.

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: * the RDPS-dependent product function; * the required RDPS-side interactions; * the acceptable timing or service conditions for those interactions; and * the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the timeout, timeliness, or equivalent detection controls; * verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected; * verify that a defined behaviour is applied when such conditions occur; and * verify that, under normal conditions, expected interactions are processed without triggering the fault-handling behaviour.

Verdict

Pass: * the local product side detects the specified failure, delay, or degradation conditions; * timeout or equivalent timeliness controls are used; and * a defined behaviour is applied when the identified conditions occur. Fail: * the local product side does not detect the relevant failure, delay, or degradation condition; or * the required defined behaviour is not applied when such a condition occurs.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for detection and timeliness controls; * evidence showing detection of failure, delay, or degradation; and * evidence showing application of the defined behaviour.
REQ-RDPS-L-AVAIL-002 — Where the availability or timeliness of interactions received from the RDPS side is necessary f…R.4.3.4 · level 2 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected RDPS-side interactions; 1. 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 1. 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 (the draft’s own)

This requirement strengthens protection by requiring controlled degraded operation or transition to a secure state, together with support for restoration of secure operation.

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: * the RDPS-dependent product function; * the required RDPS-side interactions; * the degraded behaviour or secure state defined for failure conditions; and * any locally maintained state, configuration, or other recovery information required to restore secure operation.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the degraded behaviour or secure-state mechanism; * inspect the design and configuration of the recovery mechanism, where applicable; * 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 * verify that recovery support is available and can be used to restore secure operation where such support is required.

Verdict

Pass: * the local product side applies the defined degraded behaviour or secure state under the relevant failure conditions; and * recovery support is available and usable where necessary to restore secure operation. Fail: * the local product side does not apply the defined degraded behaviour or secure state under the relevant failure conditions; or * required recovery support is absent or ineffective.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for degraded behaviour, secure state, and recovery support; and * evidence showing activation of degraded behaviour / secure state and restoration of secure operation where applicable.
REQ-RDPS-L-AVAIL-003 — Where the availability or timeliness of interactions received from the RDPS side is necessary f…R.4.3.4 · level 3 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected RDPS-side interactions; 1. 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; 1. 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; 1. support continuity of operation through failover, redundancy, or an equivalent resilience mechanism where such a mechanism is necessary.

Rationale (the draft’s own)

This requirement provides stronger protection by requiring resilience measures.

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: * the RDPS-dependent product function; * the required RDPS-side interactions; * the defined degraded behaviour or secure state; * the recovery support; and * the failover, redundancy, or equivalent resilience mechanism, where required.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the resilience mechanism used to support continuity of operation; * verify that the defined degraded behaviour or secure state is applied under the relevant failure conditions; * verify that recovery support is available where required; * 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: * the local product side supports the required resilience mechanism where necessary; * defined degraded behaviour or secure state is applied under the relevant conditions; and * continuity of operation is supported in accordance with the design where resilience is required. Fail: * a required resilience mechanism is absent or ineffective; or * the local product side fails to support continuity of operation where such support is required.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for resilience, degraded behaviour, and recovery support; and * evidence showing failover, redundancy, or equivalent continuity support where required.

R.4.4.1 — Data authenticity of interactions received from the local product sideRDPS side

REQ-RDPS-R-AUTH-001 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.1 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement protects against acceptance of interaction content whose claimed source or origin is not genuine.

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: * the RDPS-dependent product function; * the interactions received from the local product side that can influence the behaviour, state, configuration, or security of that function; * the intended local product-side endpoint for those interactions; and * the mechanism used by the RDPS side to determine the origin of the received interaction.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism used by the RDPS side to determine the origin of the relevant interaction; * verify that the origin of the interaction is checked before the interaction is acted upon; * verify that interactions from the intended local product-side endpoint are accepted; and * verify that interactions not originating from the intended local product-side endpoint are rejected or not acted upon.

Verdict

Pass: * the RDPS side verifies the origin of the relevant interaction before acting upon it; and * interactions from endpoints other than the intended local product-side endpoint are rejected or not acted upon. Fail: * the RDPS side acts upon a relevant interaction without verifying its origin; or * the RDPS side accepts and acts upon a relevant interaction not originating from the intended local product-side endpoint.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence describing how origin of the interaction is determined; * evidence showing acceptance of interactions from the intended local product-side endpoint; and * evidence showing rejection or non-processing of interactions from other endpoints.
REQ-RDPS-R-AUTH-002 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.1 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens protection against spoofed or falsely originated interaction content by requiring cryptographic assurance of origin.

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: * the RDPS-dependent product function; * the relevant received interactions; * the cryptographic mechanism used to provide assurance of origin; and * the conditions under which the RDPS side accepts or rejects those interactions.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic mechanism used to provide assurance of origin; * verify that the RDPS side checks the authenticity-protection status of the interaction before acting upon it; * verify that a valid interaction protected by the intended mechanism is accepted; and * verify that an interaction lacking valid cryptographic assurance of origin is rejected or not acted upon.

Verdict

Pass: * the RDPS side uses a cryptographic mechanism providing assurance of origin for relevant received interactions; * the RDPS side verifies that protection before acting upon the interaction; and * interactions without valid assurance of origin are rejected or not acted upon. Fail: * the RDPS side acts upon a relevant interaction without verifying cryptographic assurance of origin; or * the RDPS side accepts and acts upon an interaction for which the required authenticity mechanism is absent or invalid.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic authenticity mechanism; * traces or logs showing successful acceptance of valid protected interactions; and * traces or logs showing rejection or non-processing of interactions without valid assurance of origin.
REQ-RDPS-R-AUTH-003 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.1 · level 3 of 3

Requirement (verbatim from the interim draft)

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: 1. the cryptographic authenticity of the interaction is bound to the intended local product-side endpoint; and 1. replayed or stale interactions are detected and rejected where replay or reuse could affect the secure operation of the RDPS-dependent product function.

Rationale (the draft’s own)

This requirement provides stronger protection by requiring source-bound authenticity and replay protection.

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: * the RDPS-dependent product function; * the relevant received interactions; * the mechanism used to bind authenticity to the intended local product-side endpoint; and * the replay or freshness protection mechanism, where applicable.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism that binds the authenticity of the interaction to the intended local product-side endpoint; * inspect the design and configuration of the freshness, anti-replay, or equivalent mechanism used; * verify that a valid interaction bound to the intended local product-side endpoint is accepted; * 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 * where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.

Verdict

Pass: * the RDPS side verifies that authenticity is bound to the intended local product-side endpoint; and * replayed or stale interactions are rejected where replay or reuse could affect secure operation. Fail: * the RDPS side accepts and acts upon an interaction whose cryptographic authenticity is not bound to the intended local product-side endpoint; or * the RDPS side fails to detect and reject replayed or stale interactions where such protection is required.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for source binding and anti-replay/freshness controls; * evidence showing acceptance of valid bound interactions; and * evidence showing rejection of misbound, replayed, or stale interactions.

R.4.4.2 — Integrity of interactions received from the local product sideRDPS side

REQ-RDPS-R-INTEG-001 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.2 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement protects against loss of integrity of received interaction content.

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: * the RDPS-dependent product function; * the relevant received interactions; and * the mechanism used by the RDPS side to detect modification, substitution, corruption, or injection.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the integrity-checking mechanism; * verify that integrity is checked before the interaction is acted upon; * verify that an unmodified valid interaction is accepted; and * verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon.

Verdict

Pass: * the RDPS side checks the integrity of relevant received interactions before acting upon them; and * modified, substituted, corrupted, or injected interactions are rejected or not acted upon. Fail: * the RDPS side acts upon a relevant interaction without verifying its integrity; or * the RDPS side accepts and acts upon an altered, substituted, corrupted, or injected interaction.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence of the integrity-checking mechanism; * evidence showing acceptance of valid interactions; and * evidence showing rejection or non-processing of altered or injected interactions.
REQ-RDPS-R-INTEG-002 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.2 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens protection against unauthorized modification or substitution of received interactions.

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: * the RDPS-dependent product function; * the relevant received interactions; and * the cryptographic integrity-protection mechanism used for those interactions.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic integrity-protection mechanism; * verify that integrity verification takes place before the interaction is acted upon; * verify that a valid cryptographically protected interaction is accepted; and * verify that an interaction with missing or invalid integrity protection is rejected or not acted upon.

Verdict

Pass: * the RDPS side uses cryptographic integrity protection for relevant received interactions; * integrity verification is performed before the interaction is acted upon; and * interactions with invalid or missing integrity protection are rejected or not acted upon. Fail: * the RDPS side does not use cryptographic integrity verification where required; or * the RDPS side accepts and acts upon an interaction whose integrity protection is missing or invalid.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic integrity mechanism; * evidence showing acceptance of valid protected interactions; and * evidence showing rejection of interactions with invalid or missing integrity protection.
REQ-RDPS-R-INTEG-003 — The RDPS side shall verify, before acting upon a received interaction that can influence the be…R.4.4.2 · level 3 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement provides stronger protection by requiring cryptographic integrity protection bound to the authenticated source.

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: * the RDPS-dependent product function; * the relevant received interactions; * the authenticated source of those interactions; and * the mechanism used to bind integrity protection to that authenticated source.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the mechanism that binds integrity protection to the authenticated source; * verify that a valid interaction whose integrity protection is correctly bound to the authenticated source is accepted; * verify that an interaction with integrity protection not bound to the authenticated source is rejected or not acted upon; and * verify that integrity verification and source binding checks are performed before the interaction is acted upon.

Verdict

Pass: * the RDPS side verifies that the interaction is protected by cryptographic integrity protection bound to the authenticated source; and * interactions not correctly bound to that source are rejected or not acted upon. Fail: * the RDPS side accepts and acts upon a relevant interaction whose integrity protection is not bound to the authenticated source; or * the RDPS side acts upon the interaction before performing the required checks.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for integrity binding to authenticated source; * evidence showing acceptance of correctly bound interactions; and * evidence showing rejection of misbound interactions.

R.4.4.3 — Confidentiality of data exchanged with the local product sideRDPS side

REQ-RDPS-R-CONF-001 — Where disclosure of data exchanged with the local product side could lead to unacceptable cyber…R.4.4.3 · level 1 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement ensures confidentiality where disclosure of exchanged data could affect the security or secure operation of the RDPS-dependent product function.

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: * the RDPS-dependent product function; * the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk; and * the mechanism used by the RDPS side to protect confidentiality during exchange.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the confidentiality-protection mechanism; * verify that the identified data is protected during exchange with the local product side; and * verify that data designated as requiring confidentiality is not exchanged in an unprotected manner.

Verdict

Pass: * the RDPS side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk; and * such data is not exchanged in an unprotected manner. Fail: * the RDPS side does not protect the confidentiality of exchanged data where such protection is required; or * identified confidential data is exchanged without appropriate confidentiality protection.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design or configuration evidence identifying the protected data and the means of protection; and * evidence showing that relevant exchanged data is protected during exchange.
REQ-RDPS-R-CONF-002 — Where disclosure of data exchanged with the local product side could lead to unacceptable cyber…R.4.4.3 · level 2 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement strengthens confidentiality protection by requiring cryptographic protection during exchange.

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: * the RDPS-dependent product function; * the exchanged data requiring confidentiality protection; and * the cryptographic confidentiality-protection mechanism used during exchange.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic confidentiality-protection mechanism; * verify that the identified exchanged data is protected by that mechanism during exchange; and * verify that exchange of such data without the required cryptographic confidentiality protection is prevented.

Verdict

Pass: * relevant exchanged data is protected using cryptographic confidentiality protection; and * exchange without the required cryptographic protection is prevented. Fail: * the RDPS side exchanges relevant confidential data without cryptographic confidentiality protection; or * the configured confidentiality mechanism is not effectively applied to the relevant data exchange.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for the cryptographic confidentiality mechanism; and * evidence showing protected exchange of the relevant data.
REQ-RDPS-R-CONF-003 — Where disclosure of data exchanged with the local product side could lead to unacceptable cyber…R.4.4.3 · level 3 of 3

Requirement (verbatim from the interim draft)

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 (the draft’s own)

This requirement provides stronger protection by ensuring that confidential exchanged data is disclosed only to the intended peer endpoint.

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: * the RDPS-dependent product function; * the exchanged data requiring stronger confidentiality protection; * the intended local product-side endpoint; and * the cryptographic mechanism used to establish confidentiality protection with that endpoint.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the cryptographic confidentiality mechanism and its association with the intended local product-side endpoint; * verify that protected exchange is established with the intended local product-side endpoint; * verify that the RDPS side does not disclose the protected data to other endpoints under the same exchange context; and * 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: * confidentiality protection is established with the intended local product-side endpoint; * protected data is disclosed only to that intended endpoint; and * exchanges with other endpoints do not result in disclosure of the protected data. Fail: * the RDPS side discloses protected data without establishing confidentiality protection with the intended local product-side endpoint; or * the RDPS side discloses the protected data to endpoints other than the intended local product-side endpoint.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for endpoint-associated confidentiality protection; * evidence showing protected disclosure to the intended local product-side endpoint; and * evidence showing prevention of disclosure to other endpoints.

R.4.4.4 — AvailabilityRDPS side

REQ-RDPS-R-AVAIL-001 — Where the availability or timeliness of interactions received from the local product side is ne…R.4.4.4 · level 1 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected local product-side interactions; and 1. apply a defined behaviour for the RDPS-dependent product function.

Rationale (the draft’s own)

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.

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: * the RDPS-dependent product function; * the required local product-side interactions; * the acceptable timing or service conditions for those interactions; and * the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the timeout, timeliness, or equivalent detection controls; * verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected; * verify that a defined behaviour is applied when such conditions occur; and * verify that, under normal conditions, expected interactions are processed without triggering the fault-handling behaviour.

Verdict

Pass: * the RDPS side detects the specified failure, delay, or degradation conditions; * timeout or equivalent timeliness controls are used; and * a defined behaviour is applied when the identified conditions occur. Fail: * the RDPS side does not detect the relevant failure, delay, or degradation condition; or * the required defined behaviour is not applied when such a condition occurs.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for detection and timeliness controls; * evidence showing detection of failure, delay, or degradation; and * evidence showing application of the defined behaviour.
REQ-RDPS-R-AVAIL-002 — Where the availability or timeliness of interactions received from the local product side is ne…R.4.4.4 · level 2 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected local product-side interactions; 1. 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 1. 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 (the draft’s own)

This requirement strengthens protection by requiring controlled degraded operation or transition to a secure state, together with support for restoration of secure operation.

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: * the RDPS-dependent product function; * the required local product-side interactions; * the degraded behaviour or secure state defined for failure conditions; and * any maintained state, configuration, or other recovery information required to restore secure operation.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the degraded behaviour or secure-state mechanism; * inspect the design and configuration of the recovery mechanism, where applicable; * 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 * verify that recovery support is available and can be used to restore secure operation where such support is required.

Verdict

Pass: * the RDPS side applies the defined degraded behaviour or secure state under the relevant failure conditions; and * recovery support is available and usable where necessary to restore secure operation. Fail: * the RDPS side does not apply the defined degraded behaviour or secure state under the relevant failure conditions; or * required recovery support is absent or ineffective.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for degraded behaviour, secure state, and recovery support; and * evidence showing activation of degraded behaviour / secure state and restoration of secure operation where applicable.
REQ-RDPS-R-AVAIL-003 — Where the availability or timeliness of interactions received from the local product side is ne…R.4.4.4 · level 3 of 3

Requirement (verbatim from the interim draft)

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: 1. detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; 1. use timeout or equivalent timeliness controls for expected local product-side interactions; 1. 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; 1. 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; 1. support continuity of operation through failover, redundancy, or an equivalent resilience mechanism where such a mechanism is necessary; and

Rationale (the draft’s own)

This requirement provides stronger protection by requiring resilience measures.

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: * the RDPS-dependent product function; * the required local product-side interactions; * the defined degraded behaviour or secure state; * the recovery support; and * the failover, redundancy, or equivalent resilience mechanism, where required.

Activities

The assessment shall include the following activities: * inspect the design and configuration of the resilience mechanism used to support continuity of operation; * verify that the defined degraded behaviour or secure state is applied under the relevant failure conditions; * verify that recovery support is available where required; * 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: * the RDPS side supports the required resilience mechanism where necessary; * defined degraded behaviour or secure state is applied under the relevant conditions; and * continuity of operation is supported in accordance with the design where resilience is required. Fail: * a required resilience mechanism is absent or ineffective; or * the RDPS side fails to support continuity of operation where such support is required.

Evidence the standard asks for

The following evidence may be used to support the assessment: * design and configuration evidence for resilience, degraded behaviour, and recovery support; and * evidence showing failover, redundancy, or equivalent continuity support where required.

Correspondence to the CRA

The draft’s own correspondence table: which of its clauses address which essential requirement of CRA Annex I. This is the draft’s claim, reproduced as it stands — not Vandorisk’s judgment of coverage, and (status block above) not a presumption of conformity.

CRA provisionDraft clause(s)
Annex I, Part 1, (1)5
Annex I, Part 1, (2)(a)5.3
Annex I, Part 1, (2)(b)5.4
Annex I, Part 1, (2)(c)5.5
Annex I, Part 1, (2)(d)5.6
Annex I, Part 1, (2)(e)5.7
Annex I, Part 1, (2)(f)5.8
Annex I, Part 1, (2)(g)5.9
Annex I, Part 1, (2)(h)5.10
Annex I, Part 1, (2)(i)5.11
Annex I, Part 1, (2)(j)5.12
Annex I, Part 1, (2)(k)5.13
Annex I, Part 1, (2)(l)5.14
Annex I, Part 1, (2)(m)5.15

Where the table covers CRA Annex I Part 1 only, the Part 2 (vulnerability handling) obligations remain assessed through the horizontal CRA pack(II.1–II.8).

Threat catalogue

The 8 threats the draft derives its requirements against, verbatim:

TH-UEVU — Unknown exploitable vulnerabilities
Attacker may use unknown exploitable vulnerabilities in the product to harm the product's assets.
TH-KEVU — Known exploitable vulnerabilities
Attacker may use known exploitable vulnerabilities in the product implementation to get unauthorized access to product assets.
TH-CACC — Circumvention of access control
Attacker may get unauthorized access to product assets by exploiting gaps or weaknesses in authorization or access control.
TH-DSTP — Unauthorized access to data stored via used product
Attacker may get unauthorized access to confidential data stored on the product through acquisition of a used platform containing the product.
TH-UADT — Unauthorized access to data transmitted or stored
Attacker may use access to the connected network to compromise the confidentiality or integrity of data transmitted by the product.
TH-CONF — Access to assets via configuration errors
Attacker may use unintentional configuration errors to get unauthorized access to the product assets.
TH-AVAI — Denial of service attack on product
Attacker may use network access to product to reduce availability of product functions.
TH-DDOS — Interference with other devices
Attacker may use product functions to interfere with other devices or services.

Draft gaps

Defects and holes we found in the interim draft while building this pack — recorded rather than papered over; they will be rechecked against each new draft. A standard under consultation is allowed to have holes. A pack that hides them is not.

  • 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).

How this pack is built, and corrections

The pack is produced by a deterministic parser over the vendored draft text pinned in the source card— no model writes or rewrites any requirement. When ETSI updates the draft, the pack is rebuilt from the new text, the draft gaps are rechecked, and the result ships as a new pack version — never a silent edit.

The interim draft and, once published, the standard itself are the authoritative texts — this pack reproduces and cites them, it does not replace them, and nothing on this page is legal advice. If you find an error — a mis-parsed requirement, an applicability entry that does not match the draft, a gap we missed — write to hello@vandorisk.com. The horizontal pack this one attaches alongside is published at /pack, with every tracked vertical standard listed there.