ETSI EN 304 625

Cybersecurity (CYBER); CRA; Cybersecurity requirements for physical and virtual network interfaces · vertical pack 0.1.0 · 19 clause-5 requirements · Annex K · 24 Annex R requirements

INTERIM DRAFT (v0.0.18, 2026-07-03) — ETSI CYBER-EUSR working draft under open consultation; subject to substantial change before publication. 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-625 — 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-625 (the ETSI Labs draft repository), commit cf144e2c, retrieved 2026-09-02.
  • 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 “Physical and virtual network interfaces” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III 'Physical and virtual network interfaces' 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 physical and virtual network interfaces related to cybersecurity. The products with digital elements in scope, thereafter "network interfaces": - are specified within the "technical description" of the "category of product" number "10" by the Commission Implementing Regulation (EU) 2025/2392 [i.2] as: "Physical and virtual network interfaces" - 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. > NOTE: This reduces the scope of the vertical. Full presumption of conformity of the product will be given by complying with both the CRA Vertical standard and PT3, once they are cited in the EUOJ. Network interfaces 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]. Network interfaces whose intended purpose includes management or configuration of the product over the attached network are excluded from the present document. Network interfaces whose intended purpose includes routing, switching, or transfer of information from one attached network to a different attached network are excluded from the present document.

Applicability (the draft’s own)

5.1.1 Applicability of the requirements 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. Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product.
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.
5.1.4 Guidance for "cybersecurity-relevant" The term "cybersecurity-relevant" is intended to allow the assessor to exclude some elements of the product from assessment if they are not relevant to the essential cybersecurity requirement being assessed. The exclusion must be documented with a clear reason. It is not necessary to identify which parts of the product are cybersecurity-relevant with any precision (or at all) as long as all cybersecurity-relevant parts of the product are included in the assessment.

The 21 use cases

Applicability is declared per use case: the draft defines 21 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.

Virtual interface for research within a host systemUC-VI-ISO
* Goal: Simulate networking for research or development * Description: * Examples: Loopback interface, container interface * Product type: Virtual network interface * Physical access: N/A * Network connectivity: Only to other VMs on same system * Function: Transmit data between VMs for research or development purposes * Host system impact: Low * Complexity: Low * User administration skill: High (low risk) * Initial setup: Low risk
Vending machine internal networkUC-PH-VNI
* Goal: Connect internal machine components, no external connection * Description: * Examples: Ethernet interfaces connecting payment module to dispenser hardware * Product type: Physical network interface * Physical access: Access-controlled * Function: Send data between components * Complexity: Medium * Host system impact: Medium * User administration skill: High * Initial setup environment: Access-controlled
Vending machine, remotely managedUC-PH-VNC
* Goal: Allow remote management of devices * Description: * Examples: 5G in vending machine to service electronic payments, report * Product type: Physical network interface * Physical access: Public * Function: Allow management of device * Complexity: Medium * Host system impact: Medium * User administration skill: High * Initial setup environment: Access-controlled
Physical network interface for home IoTUC-PH-IOT
* Goal: Connect a home appliance to a home network for local control and monitoring * Description: * Examples: Smart lightbulb bluetooth module, ethernet module for coffee machines * Product type: Physical network interface * Physical access: Home * Function: Connect low sensitivity device to local private network for management * Complexity: High * Host system impact: Low * User administration skill: Low (high risk) * Initial setup environment: Access-controlled
Intranet routerUC-PH-IRO
* Goal: Connect to routers and devices in intranet * Description: * Examples: Line cards in an intranet router for enterprise office intranet * Product type: Physical network interface * Physical access: Access-controlled * Function: Connect intranet devices and routers * Complexity: High * Host system impact: Low * User administration skill: High * Initial setup environment: Access-controlled
Edge routerUC-PH-EDG
* Goal: Provide connection and filtering to public network * Description: * Examples: Line cards in an edge router for enterprise office intranet * Product type: Physical network interface * Physical access: Access-controlled * Function: Connect intranet with public network * Complexity: High * Host system impact: Medium * User administration skill: High * Initial setup environment: Access-controlled
Home router in filtered networkUC-PH-HRO
* Goal: Connect home devices and internet access point * Description: * Examples: Ethernet and wifi modules in home router behind ISP access point * Product type: Physical network interface * Physical access: Home * Function: Connect devices to each other in filtered private network * Complexity: High * Host system impact: Low * User administration skill: Low * Initial setup environment: Access-controlled
ISP access pointUC-PH-ISP
* Goal: Provide connection and filtering to public network * Description: * Examples: Cable modem or fiber card in ISP access point * Product type: Physical network interface * Physical access: Home * Function: Connect home network with public network * Complexity: High * Host system impact: Low * User administration skill: Medium (mix of professional and amateur) * Initial setup environment: Access-controlled
Virtualize data centerUC-VI-VDC
* Goal: Connect VMs in data center to each other and public network * Description: * Examples: Emulated interfaces in a business's data processing cluster * Product type: Virtual network interface * Physical access: None * Function: Share hardware, connect to filtered private network * Complexity: Medium * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
VM on multi-tenant web serverUC-VI-VMW
* Goal: Connect VMs in web server to public network * Description: * Examples: Virtual interface in container for shared web hosting provider * Product type: Virtual network interface * Physical access: None * Function: Share hardware, connect to public network * Complexity: Medium * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
Virtualize critical serverUC-VI-VMC
* Goal: Connect VMs running critical infrastructure to public network * Description: * Examples: Virtual interface in guest VM for banking infrastructure * Product type: Virtual network interface * Physical access: None * Function: Share hardware, connect to public network * Complexity: Medium * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
Virtual interface for integratorsUC-VI-VII
* Goal: Provide virtual interfaces to developers of products * Description: * Examples: Virtio network driver in virtual machine, loopback for containers * Product type: Virtual network interface * Physical access: None * Function: Share hardware, connect to public network * Complexity: High * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
Smart watchUC-PH-SMW
* Goal: Connect small mobile devices to larger mobile devices * Description: * Examples: Smart watch bluetooth/wifi, battery-powered wifi/5G hotspot * Product type: Physical network interface * Physical access: Public * Function: Connect wirelessly to public network via nearby trusted device * Complexity: High * Host system impact: High/Medium/Low * User administration skill: Low * Initial setup environment: Access-controlled
Smart meterUC-PH-SME
* Goal: Connect infrastructure device to server * Description: * Examples: Energy smart meter/data concentrator PLC connection, water or gas meters wMBUS connection, NBIoT connection, LoRaWAN connection, handy terminal to read meter data wMBUS connection, parking meter Bluetooth, etc. * Product type: Physical network interface * Physical access: Public * Function: Transmit device data to private server via private or public network * Complexity: High * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
ATMUC-PH-ATM
* Goal: Connect public infrastructure device to public network * Description: * Examples: ATM ethernet module, traffic camera LoRaWAN module * Product type: Physical network interface * Physical access: Public * Function: Connect infrastructure to filtered network to public network * Complexity: High * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
Solar panel inverterUC-PH-SPI
* Goal: Connect critical infrastructure device to server * Description: * Examples: Solar panel inverter wifi, water pump LoRaWAN, meter data concentrator WAN connection * Product type: Physical network interface * Physical access: Semi-private * Function: Remote management of critical OT devices * Complexity: High * Host system impact: High * User administration skill: High * Initial setup environment: Access-controlled
Consumer VPNUC-VI-VPN
* Goal: Encrypt/route traffic * Description: * Examples: Consumer VPN client, VPN interface in remotely managed power strip * Product type: Virtual network interface * Physical access: None * Function: Provide secure tunnel across public networks * Complexity: High * Host system impact: High * User administration skill: Low * Initial setup environment: Home
Mobile phone or tabletUC-PH-MOB
* Goal: Connect high importance mobile device to public networks * Description: * Examples: 5G modem in phone, Wifi/bluetooth module in tablet * Product type: Physical network interface * Physical access: Public * Function: Connect to public network via local wireless * Complexity: High * Host system impact: High * User administration skill: High/Medium/Low * Initial setup environment: Access-controlled
General purpose integratedUC-PH-GPI
* Goal: Connect server/desktop/laptop computer to public network * Description: * Examples: Ethernet on motherboard on server, pre-installed wifi card on laptop * Product type: Physical network interface * Physical access: Access-controlled/Home/Public * Function: Individuals accessing the public internet * Complexity: High * Host system impact: High * User administration skill: Low * Initial setup environment: Access-controlled
External USBUC-PH-USB
* Goal: Connect computer to public network * Description: * Examples: USB ethernet dongle, USB wifi dongle * Product type: Physical network interface * Physical access: Public * Function: Provide access to public network from a computer * Complexity: High * Host system impact: Medium * User administration skill: Low * Initial setup environment: Public
StandaloneUC-PH-STA
* Goal: User installs into server/laptop/desktop/etc. * Description: * Examples: PCIe ethernet card for server, wifi/bluetooth module for laptop * Product type: Physical network interface * Physical access: Public * Function: Provide access to public network from a computer * Complexity: High * Host system impact: High * User administration skill: Low * Initial setup environment: Public

Requirement index

Every requirement in one place: the 19 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-VIUC-PHUC-PHUC-PHUC-PHUC-PHUC-PHUC-PHUC-VIUC-VIUC-VIUC-VIUC-PHUC-PHUC-PHUC-PHUC-VIUC-PHUC-PHUC-PHUC-PH
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.——●●●●●●●●—●●●●●●●●●●
5.3 — No known exploitable vulnerabilities
REQ-KEV-01The product shall have no known exploitable vulnerabilities at the time of placement on the market, with the exception of known exploitable vulnerabilities that satisfy at least one of the following criteria:——●●●●●●●●●●●●●●●●●●●
5.4 — Secure by default configuration
REQ-SBD-01The product shall provide methods to disable or protect all debug or management interfaces on the product that are exposed to unauthorized users, unless doing so would prevent backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.●●●●●●●●●●●●●●●●●●●●●
REQ-SBD-02All debug or management interfaces accessible to unauthorized users shall be protected or disabled by default, unless necessary for backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.●●●●●●●●●——●●●●●—●●——
5.5 — Security updates
REQ-SU-01The product shall provide provide a method of securely updating the product via the operational environment before or during the time of first use.—————————●●—————●——●●
5.6 — Authentication and access control
REQ-AAC-01The product shall provide methods by which the operational environment may implement any necessary authentication and access control to the product.●●●●●●●●●●●●●●●●●●●●●
5.7 — Confidentiality protection
REQ-CP-01The product shall provide methods by which the operational environment may protect the confidentiality of data transmitted by or stored on the product that is necessary to the cybersecurity of the product.●●●●●●●●●●●●●●●●●●●●●
5.8 — Integrity protection
REQ-IP-01The product shall provide methods by which the operational environment may protect the integrity of data transmitted by or stored on the product that is necessary to the cybersecurity of the product.——●●●●●●●●●●●●●●●●●●●
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 process and drop invalid packets in a manner that protects the availability of the product.●●●●●●●●●●●●●●●●●●●●●
REQ-AP-02The product shall manage internal resource usage by data received over the network or from the host system in such a manner that the impact of the exhaustion of any resource on the product's cybersecurity and functions is minimised.——●●●●●●●●●●●●●●●●●●●
REQ-AP-03The product shall provide methods by which the operational environment may protect the availability of product assets necessary to the cybersecurity of the product.●●●●●●●●●●●●●●●●●●●●●
REQ-AP-04The product shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions and provide a method for the host to reset the product.————●●●●●●●●●●●●●●●●●
REQ-AP-05The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.—————●——●●●●——●●●●●●●
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.——●●●●●●●●●●●●●●●●●●●
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
No requirement of its own in this draft — addressed by REQ-ALC-01, REQ-AP-04, REQ-AP-05, REQ-MON-01 under other clauses.
5.14 — Monitoring
REQ-MON-01The product shall record cybersecurity-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.——●●●●●●●●●●●●●●●●●●●
5.15 — Factory reset and data portability
REQ-SDT-01The product shall automatically delete all user data and settings and restore to its secure-by-default state after at least one of:●●●●●●●●●●●●●●●●●●●●●
REQ-SDT-02The product shall provide a method by which an authorized user can securely read all data and settings from the product.●●●●●●●●●●●●●●●●●●●●●
Annex K — cryptography
REQ-K-CRYPTO-CONFThe product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria: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-VI-ISO Virtual interface for research within a host system · UC-PH-VNI Vending machine internal network · UC-PH-VNC Vending machine, remotely managed · UC-PH-IOT Physical network interface for home IoT · UC-PH-IRO Intranet router · UC-PH-EDG Edge router · UC-PH-HRO Home router in filtered network · UC-PH-ISP ISP access point · UC-VI-VDC Virtualize data center · UC-VI-VMW VM on multi-tenant web server · UC-VI-VMC Virtualize critical server · UC-VI-VII Virtual interface for integrators · UC-PH-SMW Smart watch · UC-PH-SME Smart meter · UC-PH-ATM ATM · UC-PH-SPI Solar panel inverter · UC-VI-VPN Consumer VPN · UC-PH-MOB Mobile phone or tablet · UC-PH-GPI General purpose integrated · UC-PH-USB External USB · UC-PH-STA Standalone. 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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). #### 5.2.1.1 CRA Relevance 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-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: not required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: 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 (e.g., length, index, hash table lookup values, packet reassembly, etc.) * allocation of product resources (e.g., buffer length, number of packet descriptors, fragmented packets, CPU-intensive operations, etc.) * incrementing or decrementing of internal counters (e.g., packet counters, event counters, etc.) * creating or populating internal data structures (e.g., parsing input to populate an array of 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

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. 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. 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 a packet and incrementing an error counter * Emitting a notification when a counter rolls over * Crashing and restarting * Terminating a thread

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 — The product shall have no known exploitable vulnerabilities at the time of placement on the mar…Clause 5.3

Requirement (verbatim from the interim draft)

The product shall have no known exploitable vulnerabilities at the time of placement on the market, with the exception of known exploitable vulnerabilities that satisfy at least one of the following criteria: * the vulnerability became known to the manufacturer within the 14 days prior to placement on the market, or * the vulnerability became known to the manufacturer within the time period permitted before addressing and remediation of the vulnerability as described in the vulnerability handling procedure for the product prior to placement on the market, or * the vulnerability became known to the manufacturer within the time period permitted before public disclosure as described in the vulnerability handling procedure for the product prior to placement on the market, or * the vulnerability has associated publicly-available documentation explaining the risk and how that risk has been mitigated

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Prevent exploitation of known exploitable vulnerabilities.

Preparation

Using the product's SBOM if applicable, HBOM if applicable, and relevant publicly accessible vulnerability databases (e.g. GCVE, EUVD), compile a list of target components. Identify a representative list of vulnerabilities that constitute known exploitable vulnerabilities according to the product's cybersecurity risk assessment, including some that became known close in time to the date of placement of the tested product on the market, but none that became known to be exploitable vulnerabilities after that date. 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

If any vulnerablities are identified, run the tests on a product placed on the market, and compare the results with the identified list of known exploitable vulnerabilities. For any false positives, document why the result does not indicate the presence of a known exploitable vulnerability.

Verdict

PASS if any of the following are fulfilled: * No vulnerabilities meeting the described criteria were identified, * no vulnerabilities were found during testing, or * all found vulnerabilities satisify any of the following: * are identified as a false positive, or * satisfy the elapsed time since discovery exception, or * satisfy the elapsed time before public disclosure exception, or * satisfy the mitigation and documentation exception Otherwise FAIL

Evidence the standard asks for

* Documented vulnerability handling policy * Product SBOM, if applicable * Product HBOM, if applicable * Description of testing tools used or manual test plan * Test reports/scan results * Sufficiency analysis of analysis of any detected vulnerabilities for false positives, elapsed time exceptions, or documented mitigations

Guidance

To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product. If the product had no known exploitable vulnerabilities before the placement of the tested product on the market (or ever), it should pass this assessment. A vulnerability may become known but be determined to be unexploitable, then later discovered to be exploitable. Thus the "exploitable" part of "known exploitable vulnerability" should be based on the determination of its exploitability at the time of placement on the market.

5.4 — Secure by default configuration

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (b). > NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.
REQ-SBD-01 — The product shall provide methods to disable or protect all debug or management interfaces on t…Clause 5.4

Requirement (verbatim from the interim draft)

The product shall provide methods to disable or protect all debug or management interfaces on the product that are exposed to unauthorized users, unless doing so would prevent backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.

Applicability

TODO - for integrators and other use cases with sophisticated users and protected environments

Objective

Secure by default configuration.

Preparation

Identify all debug or management interfaces in the product. Categorize them into those that can be protected or disabled and those that cannot. For those that can be protected or disabled, identify methods to do so, using as necessary or available: Identify an operational environment that permits testing these methods. Identify any necessary configuration, inputs, or other preparation for attempting to access these interfaces without authorization. Install the product in the identified operational environment.

Activities

For each identified interface that can be disabled or protected, and for each method, disable or protect each interface, carry out the identified testing preparations, then attempt to use the interface without authorization. For each identified interface that cannot be disabled or protected, analyse whether backwards compatibility prevents the interface from being disabled.

Verdict

PASS if all of the following are fulfilled: * All attempts to use debug or management interfaces without authorization fail, and * For all debug or management interfaces that cannot be disabled or protected, the necessity for backward compatibility and the instructions to the user to mitigate the risk are deemed sufficient. 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 * Description of methods for protecting or disabling interfaces * Logs or records of protecting or disabling interfaces * Logs or records of attempts to access interfaces * Sufficiency analysis of documentation of necessity for exposing interfaces for backward compatibility, if any

Guidance

See Clause [6.1.2] "Guidance for identifying interfaces or data processing." This requirement is intended for the use case of an integrator or distributor who may disable or protect interfaces as necessary for the use case of product in the next step of the supply chain. The initial use for the integrator is often in an operational environment in which no unauthorized users have access to the product. Authorization may be via a variety of methods: passwords, physical access to the product, host system access, etc. An attempt to access without authorization may involve trying to login without the password, attempting to use a physical interface without physical access to the device, or using an interface available to the host system without authorization on the host system. The exposure of interfaces to unauthorized users is determined by the intended purpose of the product as specified by the manufacturer and the manufacturer's cybersecurity risk assessment.
REQ-SBD-02 — All debug or management interfaces accessible to unauthorized users shall be protected or disab…Clause 5.4

Requirement (verbatim from the interim draft)

All debug or management interfaces accessible to unauthorized users shall be protected or disabled by default, unless necessary for backward compatibility and use by an appropriately sophisticated user who has been sufficiently informed of the risk and how to mitigate it.

Applicability

* UC-VI-ISO: required * UC-PH-VNI: required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: not required * UC-VI-VMC: not required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: not required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: not required * UC-PH-STA: not required

Objective

Secure by default configuration.

Preparation

Examine the product technical documentation to find all accessible debug or management interfaces, and which interfaces are necessary for backward compability. Identify which are accessible to unauthorized users in the product's intended purpose and reasonably foreseeable use.

Activities

For each debug or management interface identified in the previous step, attempt to use the interface without authorization. For any interface which is found to be usable without authorization, examine the product technical documentation for documentation of the requirement for backward compatibility and the instructions for the user to mitigate the risks.

Verdict

PASS if all of the following are fulfilled: * All attempts to use debug or management interfaces not necessary for backward compatibility without authorization fail, and * Analysis of the necessity for backward compatibility of interfaces that cannot be disabled or protected, if any, is deemed sufficient, and * Mitigation and information for the user for any such interfaces is deemed sufficient Otherwise FAIL

Evidence the standard asks for

* Pictures of physical interfaces to the product, if applicable * Descriptions of identified debug or management interfaces * Logs or records of protecting or disabling interfaces * Logs or records of attempts to access interfaces * Sufficiency analysis of documentation of necessity for any unauthorized access for backward compatibility, if any * Sufficiency analysis of instructions to user for mitigating risks, if any

Guidance

Only interfaces that would be exposed to unauthorized users need be disabled or protected. Which interfaces are determined by the intended purpose and reasonably foreseeble use specified by the manufacturer, and the manufacturer's risk assessment.

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 provide provide a method of securely updating the product via the operational…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall provide provide a method of securely updating the product via the operational environment before or during the time of first use.

Applicability

TODO - how to express no need to update? * UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: not required * UC-PH-IOT: not required * UC-PH-IRO: not required * UC-PH-EDG: not required * UC-PH-HRO: not required * UC-PH-ISP: not required * UC-VI-VDC: not required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: not required * UC-PH-SMW: not required * UC-PH-SME: not required * UC-PH-ATM: not required * UC-PH-SPI: not required * UC-VI-VPN: required * UC-PH-MOB: not required * UC-PH-GPI: not required * UC-PH-USB: required * UC-PH-STA: required

Objective

Prevent exploitation of known 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 (e.g., read a version number from the product). 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 succeds. 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 firmware, read the version number from the logs of the host system, then install a different version of the firmware and read the version number from that.

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 provide methods by which the operational environment may implement any necess…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall provide methods by which the operational environment may implement any necessary authentication and access control to the product.

Applicability

* UC-VI-ISO: required * UC-PH-VNI: required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: 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

Guidance

The product may provide security functions that the operational environment may make use of to provide authentication and access control for a product that integrates this product as a component. But products in the scope of the present document are not required to provide authentication and access control independently of their operational environment. > NOTE: The scope of this standard could be potentially be extended to cover products whose intended purpose and reasonably foreseeable use requires authentication and access control in their secure-by-default configuration. One way to do this is to copy the relevant requirements from related standards, such as those for routers or firewalls.

5.7 — Confidentiality protection

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (e).
REQ-CP-01 — The product shall provide methods by which the operational environment may protect the confiden…Clause 5.7

Requirement (verbatim from the interim draft)

The product shall provide methods by which the operational environment may protect the confidentiality of data transmitted by or stored on the product that is necessary to the cybersecurity of the product.

Applicability

* UC-VI-ISO: required * UC-PH-VNI: required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Protect confidentiality of data transmitted by or stored on the product.

Preparation

Identify methods the product provides for confidentiality protection of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require confidentiality protection. For each identified asset, identify the methods to protect its confidentiality and any necessary configuration, inputs, or other preparation for testing confidentiality protection of that product asset. Install the product in the identified operational environment.

Activities

For each method and each type of data identified, carry out the identified testing preparations and attempt to read the confidentiality protected data without the necessary authorization.

Verdict

PASS if every attempt to read the confidentiality protected data without the necessary authorization fails. Otherwise FAIL

Evidence the standard asks for

* Descriptions of types of data requiring confidentiality protection * Records of configuration, input, and/or preparation for each test * Logs of read attempts and their results

Guidance

Many products in the scope of the present document require data confidentiality protection only on data assets that are only accessible from the host system, which is usually trusted. E.g., encryption keys stored on the network interface may only be transmitted to and from the host system over the host system bus. In this situation, a cybersecurity risk assessment may conclude that, for the product integrating the network interface, the risk of an threat actor reading the data transmitted over the system bus is already low enough to present an acceptable risk without further treatment. Examples of data that might need to be protected by the operational environment: * Firmware on a physical network device * Software comprising a virtual network device * Contents of memory in the product * Confidential cryptographic materials stored on the device * Packet data while it is being copied (transmitted over the system bus) from the host to the network interface Examples of attempts to read data without authorization: * Use the operating system interface to read cryptographic material from the product without necessary operating system privileges * Attempt to read the memory mapped to the network interface's registers and memory without the necessary memory permissions * Attempt to decrypt encrypted data sent over the network without the private cryptographic key The product may provide security functions that the operational environment may make use of to provide confidentiality protection for a product that integrates this product as a component. But products in the scope of the present document are not required to provide confidentiality protection independently of their operational environment.

5.8 — Integrity protection

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (f).
REQ-IP-01 — The product shall provide methods by which the operational environment may protect the integrit…Clause 5.8

Requirement (verbatim from the interim draft)

The product shall provide methods by which the operational environment may protect the integrity of data transmitted by or stored on the product that is necessary to the cybersecurity of the product.

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Protect integrity of data transmitted by or stored on the product.

Preparation

Identify methods the product provides for integrity protection of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require integrity protection. For each identified asset, identify the methods to protect its integrity and any necessary configuration, inputs, or other preparation for testing integrity protection of that product asset. Install the product in the identified operational environment.

Activities

For each method and each type of data identified, carry out the identified testing preparations and attempt to modify the integrity protected data without the necessary authorization.

Verdict

PASS if every attempt to modify the integrity protected data without the necessary authorization fails or is detected. Otherwise FAIL

Evidence the standard asks for

* Descriptions of types of data requiring integrity protection * Records of configuration, input, and/or preparation for each test * Logs of modification attempts and their results

Guidance

Many products in the scope of the present document may require data integrity protection only on data assets only accessible from the host system. E.g. encryption keys stored on the network interface may only be transmitted to and from the host system over the host system bus. In this situation, a cybersecurity risk assessment may conclude that, for the product integrating the network interface, the risk of an threat actor modifying the data transmitted over the system bus is already low enough to present an acceptable risk without further treatment. Examples of data that might need to be protected by the operational environment: * Firmware on a physical network device * Software comprising a virtual network device * Contents of memory in the product * Confidential cryptographic materials stored on the device * Packet data while it is being copied (transmitted over the system bus) from the host to the network interface Examples of attempts to modify data without authorization: * Use the operating system interface to configure the network interface without the necessary operation system privileges * Attempt to write to the memory mapped to the network interface's registers and memory without the necessary memory permissions * Attempt to write to the file containing the virtual network interface's executable without the necessary file system permissions The product may provide security functions that the operational environment may make use of to provide integrity protection for a product that integrates this product as a component. But products in the scope of the present document are not required to provide integrity protection independently of their operational environment to protect their own cybersecurity. Products may choose to implement integrity protection of data stored or transmitted for other reasons, such as to satisfy regulatory requirements by preventing an authorized user on the host system from installing non-conforming firmware.

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-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: not required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: 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

The product operation can require storing information relevant for the protocol implementation like out-of-order TCP packets, that are later recombined for the receiver as a continuous stream of information. This can be often considered to be part of the core functionality of the product. Outside of the core functionality, the default set size of data that needs to be collected from the operation is zero. Therefore: > Example DM-01-1: The product supports NetFlow protocol and collects information from traffic going through the interface. > Example DM-01-2: The product is a managed interface and supports a variety of different collectable metrics which are by default off, but the collection and reporting can be activated remotely. > Example DM-01-3: The product is purpose-built for high level application co-operation and participates on the content delivery network function by storing most frequent replies in the network interface volatile memory. The replies are served directly from the memory without relying the request forward. Key information and metrics are collected and relied for the application.

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 process and drop invalid packets in a manner that protects the availability o…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall process and drop invalid packets in a manner that protects the availability of the product.

Applicability

TODO

Objective

Maintain product availability during denial-of-service attacks.

Preparation

For each type of packet format processed by the product, order the fields by least to most expensive to process, approximately. Identify fields in the packet formats processed by the product that would make the packet invalid.

Activities

Measure the availability of the product while processing different kinds of invalid packets. Record whether invalid packets were dropped or accepted. Analyse the availability of the product for indications that the product is doing significantly more processing of an invalid packet than necessary to reject it.

Verdict

PASS if all of the following are fulfilled: * All invalid packets were rejected, and * the availability of the product was reasonably maintained, and * any significant reduction of availability was necessary to the product's intended purpose. Otherwise FAIL

Evidence the standard asks for

* Description of types of invalid packets * Logs of packet rejection or acceptance * Logs of measurements of product availability * Sufficiency analysis of product availability

Guidance

One method to probe the efficiency of invalid packet processing is to construct pairs of invalid packet formats that could both be rejected with the same process, but one packet could potentially require significantly more resources to process if the packet processing was done in a less efficient order. Then send a large number of each kind of packet to the device and measure resource usage. E.g., given a packet with a 4 byte destination address field and a 1000 byte payload with a checksum, create a packet with an invalid address field and a correct checksum and a packet with an invalid address and an invalid checksum. Then measure the packet processing rate for each kind of packet. This may reveal whether the packet rejection code is unnecessarily validating the packet checksum for a packet it will reject anyway. Efficiently dropping invalid packets may be accomplished by checking the frame length, header fields, and destination address in order from least to most computationally expensive, and dropping the packet as soon as any field is found to be invalid without further processing.
REQ-AP-02 — The product shall manage internal resource usage by data received over the network or from the…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall manage internal resource usage by data received over the network or from the host system in such a manner that the impact of the exhaustion of any resource on the product's cybersecurity and functions is minimised.

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-IOT: REQ-AP-02 or REQ-AP-03 * UC-PH-IRO: REQ-AP-02 or REQ-AP-03 * UC-PH-EDG: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-HRO: REQ-AP-02 or REQ-AP-03 * UC-PH-ISP: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-VI-VDC: REQ-AP-02 or REQ-AP-03 * UC-VI-VMW: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-VI-VMC: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-VI-VII: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-SMW: REQ-AP-02 or REQ-AP-03 * UC-PH-SME: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-ATM: REQ-AP-02 or REQ-AP-03 * UC-PH-SPI: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-VI-VPN: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-MOB: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-GPI: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-USB: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03 * UC-PH-STA: (REQ-AP-01 and REQ-AP-02) or REQ-AP-03

Objective

Maintain product availability during denial-of-service attacks.

Preparation

Identify product resources that may be exhausted by data received over the network. For each resource, prepare a sequence of network data that if received by the product (possibly with specific timing) will exhaust that resource. Identify ways to measure the availability of product functions and monitor any impact on product cybersecurity. Identify the performance of the product with maximum sustainable usage of each resource by incoming network data.

Activities

For each resource, send the network data that will exhaust that resource to the interface while measuring and monitoring availability and cybersecurity. Compare the results to the performance with the maximum sustainable usage of that resource. Analyse the monitoring for any degradation to cybersecurity.

Verdict

PASS if all of the following are fulfilled: For each resource and network data tested, * the availability of the product was not significantly degraded compared to the maximum sustainable usage, and * the cybersecurity of the product was not compromised. Otherwise FAIL

Evidence the standard asks for

* Set of inputs * Logs of measurements and monitoring of resource usage, availability, and cybersecurity * Explanation of choice of metrics * Sufficiency analysis of availability * Sufficiency analysis of cybersecurity

Guidance

Some examples of internal resources that may be exhausted: * packet buffers * descriptor rings * processor time Some ways to exhaust the resources are to send packets: * faster than the product can process them * with the maximum valid length as fast as possible * that are fragmented and must be reassembled in the network interface * that are encrypted * that contain a large number of unusual or optional fields Some ways to measure the cybersecurity of the product: * data transferred to the host or network are correct * product does not reset * product continues to function correctly * product metrics are correct and consistent with input
REQ-AP-03 — The product shall provide methods by which the operational environment may protect the availabi…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall provide methods by which the operational environment may protect the availability of product assets necessary to the cybersecurity of the product.

Applicability

TODO

Objective

Maintain product availability during denial-of-service attacks.

Preparation

Identify methods the product provides for availability protection of cybersecurity-relevant product assets. Identify an operational environment that permits testing these methods. Identify product assets that require availability protection. For each identified asset, identify the methods to protect its availability and any necessary configuration, inputs, or other preparation for testing availability protection of that product asset. Install the product in the identified operational environment.

Activities

For each method and each type of asset identified, carry out the identified testing preparations and measure its availability.

Verdict

PASS if for all tests, the availability of the product asset is deemed sufficient. Otherwise FAIL

Evidence the standard asks for

* Descriptions of types of data requiring integrity protection * Records of configuration, input, and/or preparation for each test * Logs of availability measurements * Sufficiency analysis of analysis of availability of product asset

Guidance

See the other requirements in the present clause for examples of testing availability of product assets.
REQ-AP-04 — The product shall implement a mechanism to notify the host system when it detects that it is no…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall implement a mechanism to notify the host system when it detects that it is no longer able to perform its functions and provide a method for the host to reset the product.

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: not required * UC-PH-IOT: not required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Maintain product availability during denial-of-service attacks.

Preparation

Identify the conditions that indicate that the product is not performing its functions sufficiently. Identify representative methods of causing the product to enter that condition.

Activities

Use each identified method and monitor notifications to the host.

Verdict

PASS if, after causing the product to enter each condition, the host system receives a notification. Otherwise FAIL

Evidence the standard asks for

* Description of identified conditions and methods * Log of using method * Log of notifications received on host system * Log of device activity and/or state * Packet captures

Guidance

Forcing the product into a non-functional state can often be done by enabling and using testing interfaces.
REQ-AP-05 — The product shall implement a mechanism to trigger an automatic reset when it detects that it i…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall implement a mechanism to trigger an automatic reset when it detects that it is no longer able to perform its functions.

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: not required * UC-PH-IOT: not required * UC-PH-IRO: not required * UC-PH-EDG: required * UC-PH-HRO: not required * UC-PH-ISP: not required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: not required * UC-PH-SME: not required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Maintain product availability during denial-of-service attacks.

Preparation

Identify the conditions that indicate that the product is not performing its functions sufficiently. Identify representative methods of causing the product to enter that condition.

Activities

Use each identified method and monitor the product functions.

Verdict

PASS if, after causing the product to enter each condition, the product regains the ability to perform its functions without outside intervention. Otherwise FAIL

Evidence the standard asks for

* Description of identified conditions and methods * Log of using method * Log of device activity and/or state * Packet captures

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-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: 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

Guidance

Denial of service attacks over the network often use traffic reflection or amplification techniques, in which the threat actor sends packet to third party devices with a spoofed source address. The third party then sends a response packet to the spoofed source destination - a reflection attack. If the response is larger than the packet it is responding to, then it is an amplification attack. By minimising or rate-limiting the data sent to potentially spoofed source addresses, a product can reduce its interference with other devices. This requirement operates at the link layer (IP) or data link layer and/or physical layer (OSI model). Interfaces of this type are relatively uncommon for the products in the scope of the present document and are mostly located outside the product, in higher layers of the network stack. Non-interference at higher layers in the network stack is the responsibility of the operational environment.

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-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: not required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: 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 and reasonably foreseeable use 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).

This draft defines no requirement of its own under this clause; it records the clause as addressed by REQ-ALC-01, REQ-AP-04, REQ-AP-05, REQ-MON-01.

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 cybersecurity-relevant internal events, including but not limited to c…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall record cybersecurity-relevant internal events, including but not limited to changes to configuration and access or modification of data and functions. The product shall provide an opt-out mechanism.

Applicability

* UC-VI-ISO: not required * UC-PH-VNI: not required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Monitoring and recording cybersecurity-relevant events.

Preparation

Identify cybersecurity-relevant events that should be recorded on the product or communicated to the operational environment. Identify methods to trigger each event.

Activities

For each type of cybersecurity-relevant internal event 1. trigger the event on the product, and 2. check if the event was recorded internally on the product, or the product sent a notification to the host, or the event was recorded in some other manner.

Verdict

PASS if any of the following are fulfilled: For each triggered event: * the product recorded the event internally, or * the product notified the host of the event, or * the event was recorded in some other manner. Otherwise FAIL

Evidence the standard asks for

* Description of identified events * Method of triggering events * Logs of triggering events * Logs of internal event records and/or host notifications

Guidance

Examples of cybersecurity-relevant events: * configuration changes * state changes * data transmitted * packet counters * invalid packets * dropped packets * resource exhaustion * cryptographic material changes

5.15 — Factory reset and data portability

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (m).
REQ-SDT-01 — The product shall automatically delete all user data and settings and restore to its secure-by-…Clause 5.15

Requirement (verbatim from the interim draft)

The product shall automatically delete all user data and settings and restore to its secure-by-default state after at least one of: 1. a power cycle, or 2. a specific reset command, or 3. a reinstallation, if necessary with a specified delete option, or 4. a specific delete command.

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: * UC-VI-ISO: required * UC-PH-VNI: required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

Objective

Secure deletion.

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-SDT-02 — The product shall provide a method by which an authorized user can securely read all data and s…Clause 5.15

Requirement (verbatim from the interim draft)

The product shall provide a method by which an authorized user can securely read all data and settings from the product.

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: * UC-VI-ISO: required * UC-PH-VNI: required * UC-PH-VNC: required * UC-PH-IOT: required * UC-PH-IRO: required * UC-PH-EDG: required * UC-PH-HRO: required * UC-PH-ISP: required * UC-VI-VDC: required * UC-VI-VMW: required * UC-VI-VMC: required * UC-VI-VII: required * UC-PH-SMW: required * UC-PH-SME: required * UC-PH-ATM: required * UC-PH-SPI: required * UC-VI-VPN: required * UC-PH-MOB: required * UC-PH-GPI: required * UC-PH-USB: required * UC-PH-STA: required

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.

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

The draft’s Annex K cryptography provisions, as this pack makes them answerable. Everything inside the entries 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 — The product’s default configuration shall only use cryptographic mechanisms that meet at least…Annex K

Requirement (verbatim from the interim draft)

The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria: 1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1]; 2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1] and meets at least one of the following conditions: - a) the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s), following consideration of the criteria specified in item 2.b; - b) where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria: - i) the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1]; - ii) the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognized European, international or sector-specific standards development organization, or by an industry specification organization accountable for the relevant specification, including CEN, CENELEC, ETSI, ISO, IEC, ISO/IEC JTC 1, IETF, IEEE, ITU-T, NIST, 3GPP, O-RAN Alliance, BSI, ACN, C2SP; or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognized national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including BSI TR-02102-1, BSI TR-02102-2, BSI TR-02102-3 and BSI TR-02102-4; - iii) the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification; - iv) the cryptographic properties of the cryptographic mechanism are known; - v) no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties; - vi) the cryptographic mechanism is required for a specific set of product functions; 3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).

Applicability

Per clause 5.1.2: "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."

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

Guidance

The assessment path depends on the mechanism class claimed under K.1.1: ACM-listed mechanisms are assessed per K.1.2.2 (loaded here), ACM-extended mechanisms per K.1.2.3 and interoperability-based mechanisms per K.1.2.4 — all three blocks are carried in this pack's annexK.cryptoConfigAssessments.
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.

Applicability

Per clause K.2.1: applies where the product's default configuration uses a cryptographic mechanism with a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product.

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

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.2. Where a security property is identified as relevant for a given asset in the asset tables of Clause R.3.2, 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: - a) data authenticity of interactions; - b) integrity of interactions; and - c) confidentiality of exchanged data. For DA-RDPS-002, the primary requirement family considered for applicability is availability. Where the three-level requirement scenario is selected, the applicable level within each selected requirement family should be determined in accordance with the use case, security profile, equivalent classification, or risk-based applicability model defined by the concerned vertical standard. Where the three-level requirement scenario is used, the requirements within a given requirement family represent alternative levels of rigour 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). Where the mono-level requirement scenario is selected, the corresponding mono-level requirement should be considered for the selected requirement family. > NOTE: The mono-level requirement proposals are alternatives to the corresponding three-level requirement sequences and are not additional requirements to be applied together with them.

R.4.3 — 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 · 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 · 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 · 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: - a) the cryptographic authenticity of the interaction is bound to the intended RDPS-side endpoint; and - b) 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 — 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 · 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 · 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 · 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 — 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 · 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 · 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 · 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 — 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 · 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: - a) detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected RDPS-side interactions; and - c) 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 · 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: - a) detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected RDPS-side interactions; - c) 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 - d) 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 · 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: - a) detect unavailability of the RDPS side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected RDPS-side interactions; - c) 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; - d)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; - e) 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.
R.4.4 RDPS side requirements

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 — 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 · 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 · 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 · 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: - a) the cryptographic authenticity of the interaction is bound to the intended local product-side endpoint; and - b) 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 — 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 · 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 · 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 · 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 — 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 · 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 · 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 · 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 — 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 · 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: - a) detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected local product-side interactions; and - c) 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 · 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: - a) detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected local product-side interactions; - c) 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 - d) 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 · 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: - a) detect unavailability of the local product side, unacceptable delay of expected interactions, or intolerable degradation of the interaction; - b) use timeout or equivalent timeliness controls for expected local product-side interactions; - c) 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; - d) 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; and - e) 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.
R.4.5 Threats ↔ Requirements mapping Table R.4: Threats ↔ Requirements mapping | Threat ID | Requirement(s) – Local product side | Requirement(s) – RDPS side | |-----------|----------------------------------------------------------------------|----------------------------------------------------------------------| | T-RDPS-01 | REQ-RDPS-L-AUTH-001<br>REQ-RDPS-L-AUTH-002<br>REQ-RDPS-L-AUTH-003 | REQ-RDPS-R-AUTH-001<br>REQ-RDPS-R-AUTH-002<br>REQ-RDPS-R-AUTH-003 | | T-RDPS-02 | REQ-RDPS-L-INTEG-001<br>REQ-RDPS-L-INTEG-002<br>REQ-RDPS-L-INTEG-003 | REQ-RDPS-R-INTEG-001<br>REQ-RDPS-R-INTEG-002<br>REQ-RDPS-R-INTEG-003 | | T-RDPS-03 | REQ-RDPS-L-CONF-001<br>REQ-RDPS-L-CONF-002<br>REQ-RDPS-L-CONF-003 | REQ-RDPS-R-CONF-001<br>REQ-RDPS-R-CONF-002<br>REQ-RDPS-R-CONF-003 | | T-RDPS-04 | REQ-RDPS-L-AVAIL-001<br>REQ-RDPS-L-AVAIL-002<br>REQ-RDPS-L-AVAIL-003 | REQ-RDPS-R-AVAIL-001<br>REQ-RDPS-R-AVAIL-002<br>REQ-RDPS-R-AVAIL-003 |

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.2
Annex I, Part 1, (2)(b)5.3
Annex I, Part 1, (2)(c)5.4
Annex I, Part 1, (2)(d)5.5
Annex I, Part 1, (2)(e)5.6
Annex I, Part 1, (2)(f)5.7
Annex I, Part 1, (2)(g)5.8
Annex I, Part 1, (2)(h)5.9
Annex I, Part 1, (2)(i)5.10
Annex I, Part 1, (2)(j)5.11
Annex I, Part 1, (2)(k)5.12
Annex I, Part 1, (2)(l)5.13
Annex I, Part 1, (2)(m)5.14
Annex I, Part 25.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 7 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-DSTP — Compromise of data stored on product
Attacker may get unauthorized access to confidential data stored on the product through acquisition of a used product or during transfer of user data and settings from one product to another.
TH-CONF — Access to assets via configuration errors
Attacker may use unintentional configuration errors to get unauthorized access to the product assets.
TH-UADT — Unauthorized access to data transmitted
Attacker may use access to the attached network to compromise the confidentiality or integrity of data transmitted by the product.
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-SBD-01: the draft's Applicability clause carries no per-use-case bullets (verbatim: "TODO - for integrators and other use cases with sophisticate"…) — treated as applicable to every use case until the draft completes it.
  • REQ-AP-01: the draft's Applicability clause carries no per-use-case bullets (verbatim: "TODO"…) — treated as applicable to every use case until the draft completes it.
  • REQ-AP-02: several use-case bullets carry alternative structures (e.g. "(REQ-AP-01 and REQ-AP-02) or REQ-AP-03") instead of plain required/not-required — normalised to "required" with the verbatim alternatives preserved in applicabilityText.
  • REQ-AP-03: the draft's Applicability clause carries no per-use-case bullets (verbatim: "TODO"…) — treated as applicable to every use case until the draft completes it.
  • REQ-AP-01: the clause-6 heading #### 6.10.2.6 carries no subsection title in this interim draft; its body reads as guidance and is loaded as the assessment guidance.
  • Annex A's correspondence table still uses the skeleton's clause numbers (e.g. it maps Annex I Part 1 (2)(a) to Clause 5.2) while the document body places 'No known exploitable vulnerabilities' in clause 5.3 — the table is one clause off from the body throughout. Rows are reproduced verbatim from the draft; the per-topic overviews state which CRA item each clause actually addresses.
  • Annex B numbers its threats B.4.3.1–B.4.3.6 and then B.4.3.8 — B.4.3.7 does not exist in this interim draft; the 7 published threats are loaded.
  • Annex K requirement ids REQ-K-CRYPTO-CONF and REQ-K-CRYPTO-AGILITY are Vandorisk handles for clauses K.1.1 and K.2.1 — the draft defines those requirements without ids of its own. K.3.1 and K.4.1 are conditional refinements of K.1.1 items 2 and 3 and are assessed under K.1.2 (K.3.3/K.4.3 cross-reference), so they are not separate entries.
  • Annex R publishes two alternative drafting scenarios and R.4.1/R.4.2 say they are NOT cumulative: the three-level requirement scenario (R.4.3/R.4.4, 24 requirements, loaded here — within a family the levels are alternative rigour levels and one applicable level is selected) and mono-level consolidated proposals marked '(for discussion)' (REQ-RDPS-L/R-AUTH/INTEG/CONF/AVAIL-0TK, 8 ids, with their R.5.5 assessment cases). The mono-level TK proposals are consciously not extracted.
  • Annex B clause B.7 references 'REQ-DRT-03 (MI-SDRF) Secure data read from product' — an id that exists nowhere else in the draft; clause 5.15.3 defines the same provision as REQ-SDT-02. The dangling id is not loaded.
  • Editor's notes (the draft's <mark>…</mark> spans, including large TODO commentary in clause 5.3.2.3's guidance) are stripped from all extracted text — they address the ETSI drafters, not the manufacturer.
  • Annex A carries one bare 'Annex I, Part 2' row pointing at clause 5.15 with no per-item correspondence for 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.