{"packId":"en-304-621","packVersion":"0.1.0","standard":{"reference":"ETSI EN 304 621","title":"Cybersecurity (CYBER); CRA; Cybersecurity requirements for network management systems","status":"INTERIM DRAFT (v1.0.4, 2026-07-20) — draft EN produced by ETSI TC CYBER, submitted for the combined Public Enquiry and Vote phase (SRdAP) and subject to change before publication. Not cited in the Official Journal: conformance confers NO presumption of conformity today.","sourceUrl":"https://labs.etsi.org/rep/stan4cra/en-304-621","sourceCommit":"03df4d2a","retrievedAt":"2026-09-02","license":"BSD-3-Clause, © ETSI. Redistributed with attribution as the license requires; the verbatim requirement and assessment text below is reproduced from the interim draft.","licenseText":"Copyright 2025 ETSI\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n1. Redistributions of source code must retain the above copyright notice,\n this list of conditions and the following disclaimer.\n2. Redistributions in binary form must reproduce the above copyright notice,\n this list of conditions and the following disclaimer in the documentation\n and/or other materials provided with the distribution.\n3. Neither the name of the copyright holder nor the names of its contributors\n may be used to endorse or promote products derived from this software without\n specific prior written permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.\nIN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,\nINDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,\nBUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\nDATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF\nLIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE\nOR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED\nOF THE POSSIBILITY OF SUCH DAMAGE."},"appliesTo":{"craCategory":"important-1","annexIIIItem":"Network management systems","note":"Attaches to a product whose CRA classification matched the Annex III network-management-systems item, or manually."},"scope":"The present document specifies technical requirements and corresponding assessment criteria for NMS related to cybersecurity.\nThe products with digital elements in scope, thereafter \"NMS\": are specified within the \"technical description\" of the \"category of product\" number \"6\" by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [i.2\\] as:\n\n```\nProducts with digital elements that manage connected network elements, such as servers, routers, switches, workstations, printers or mobile devices, by monitoring them and controlling their network operations and configuration.\nThis category includes but is not limited to end-to-end management systems and dedicated configuration management systems, such as controllers for software-defined networking.\n```\n\nThe products with digital elements in scope are only covered within the product context described in clause 4 of this document.\n\nThe present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [i.1\\] Annex I Part I under the conditions identified in annex A.\n\nThis includes, but is not limited to, Mobile Device Management systems and Software Defined Networking , e.g when an SDN-controller is a stand-alone product using a network management protocol as its South Bound Interface (SBI).\n\nNMS intended for use in the industrial OT (Operational Technology)[i.18\\] domain are excluded from the scope of the present document.\n\nAn NMS is a product controlling at least partially connected devices with network access.\nDespite its central positioning, an NMS can be an aggregate of several components, including but not limited to: end-to-end management systems, dedicated configuration management systems, or controllers for software-defined networking.\n\nNMS can be composed of several components or can implement additional functions that are outside the scope of the present document.\n\n> Example: Aggregate product design would be an implementation where the operating system acts as an abstraction layer for the system(s) that host the NMS, or the networking interfaces.","applicabilityIntro":"The technical documentation referenced in this clause is intended to describe the product design, dependencies, and implemented measures relevant to demonstrate conformity with the applicable requirements of the present document.\n\nThe technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.\n\nThe requirements in this section are unconditionally applicable, unless specifically indicated with a conditional phrasing, or the functionality is implemented with RDPS.\n\nWhen requirements are divided into low-medium-high categories, the categories are cumulative.\nMedium requirement level shall implement also requirements listed in low level.\nHigh requirement level shall implement all requirements in the defined set of requirements as the requirements are cumulative.\n\n**Table 5.1-1: Mapping of UC-1-HOME, UC-2-ENTER-S, UC-2-ENTER-M, UC-2-ENTER-L and UC-3-TELCO to a requirement set based on annex A security analysis**\n\n| Requirement set | UC-1-HOME | UC-2-ENTER-S | UC-2-ENTER-M | UC-2-ENTER-L | UC-3-TELCO |\n| --------------- | --------- | ------------ | ------------ | ------------ | ---------- |\n| CYB_GENERAL | low | medium | high | high | high |\n| CYB_OPS | all | all | all | all | all |\n| KEV_EXPLOIT | all | all | all | all | all |\n| SBD_TECH | all | all | all | all | all |\n| SU_UPDATES | all | all | all | all | all |\n| AAC_AUTH | all | all | all | all | all |\n| AAC_MACHINE | all | all | all | all | all |\n| CON_INGEST | all | all | all | all | all |\n| CON_CRYPTO | all | all | all | all | all |\n| CON_CHANNEL | all | all | all | all | all |\n| INT_CONF | all | all | all | all | all |\n| INT_ROTATE | all | all | all | all | all |\n| DM_RETENTION | all | all | all | all | all |\n| AP_HA | low | medium | medium | medium | high |\n| IM_SEGMENT | low | medium | medium | medium | high |\n| MAS_TECH | all | all | all | all | all |\n| EMM_ROUTE | high | high | medium | medium | high |\n| MON_LOG | low | medium | medium | meidum | high |\n| MON_METRICS | all | all | all | all | all |\n| DRT_DELETE | all | all | all | all | all |\n\n> NOTE: Because (RF-ADMIN is High or RF-NUM is High) is true for both UC-1-HOME and UC-3-TELCO, both use cases require high risk level from EMM_ROUTE requirements.\n\n**Table 5.1-2: Mapping of UC-4-SDN, UC-5-HYBRID, UC-6-IOT, UC-7-ICT and UC-8-FLEET to a requirement set based on annex A security analysis**\n\n| Requirement set | UC-4-SDN | UC-5-HYBRID | UC-6-IOT | UC-7-ICT | UC-8-FLEET |\n| --------------- | -------- | ----------- | -------- | -------- | ---------- |\n| CYB_GENERAL | high | high | medium | high | medium |\n| CYB_OPS | all | all | all | all | all |\n| KEV_EXPLOIT | all | all | all | all | all |\n| SBD_TECH | all | all | all | all | all |\n| SU_UPDATES | all | all | all | all | all |\n| AAC_AUTH | all | all | all | all | all |\n| AAC_MACHINE | all | all | all | all | all |\n| CON_INGEST | all | all | all | all | all |\n| CON_CRYPTO | all | all | all | all | all |\n| CON_CHANNEL | all | all | all | all | all |\n| INT_CONF | all | all | all | all | all |\n| INT_ROTATE | all | all | all | all | all |\n| DM_RETENTION | all | all | all | all | all |\n| AP_HA | high | high | medium | medium | high |\n| IM_SEGMENT | high | high | medium | medium | low |\n| MAS_TECH | all | all | all | all | all |\n| EMM_ROUTE | high | high | medium | medium | high |\n| MON_LOG | high | high | medium | medium | high |\n| MON_METRICS | all | all | all | all | all |\n| DRT_DELETE | all | all | all | all | all |\n\n**Table 5.1-3: Mapping of UC-9-RESEARCH, UC-10-AIRGAP and UC-11-WATER to a requirement set based on annex A security analysis**\n\n| Requirement set | UC-9-RESEARCH | UC-10-AIRGAP | UC-11-WATER |\n| --------------- | ------------- | ------------ | ----------- |\n| CYB_GENERAL | low | low | medium |\n| CYB_OPS | all | all | all |\n| KEV_EXPLOIT | all | all | all |\n| SBD_TECH | all | all | all |\n| SU_UPDATES | all | all | all |\n| AAC_AUTH | all | all | all |\n| AAC_MACHINE | all | all | all |\n| CON_INGEST | all | all | all |\n| CON_CRYPTO | all | all | all |\n| CON_CHANNEL | all | all | all |\n| INT_CONF | all | all | all |\n| INT_ROTATE | all | all | all |\n| DM_RETENTION | all | all | all |\n| AP_HA | none | none | low |\n| IM_SEGMENT | none | none | low |\n| MAS_TECH | all | all | all |\n| EMM_ROUTE | none | high | medium |\n| MON_LOG | none | high | low |\n| MON_METRICS | all | all | all |\n| DRT_DELETE | all | all | all |\n\nThe selection of required level for is described in [Annex B](#annex-b-informative-security-analysis).","useCases":[{"id":"UC-1-HOME","title":"Home NMS","description":"In this use case, a home network device discovers or is being discovered by another device in the same subnetwork through provided network management functions.\nThe device can act as a gateway or an access point providing connectivity for the user's home to outside networks, usually public.\nAccess points are devices such as a router, switch, modem, or other wireless or wired device controlled and governed by the NMS and physically deployed to the service requesting users' home.\n\nThe device can make the upstream connection technology transparent to the user.\nDepending on the available infrastructure in the deployment location, connectivity can be through a variety of alternatives, including a mobile network or fiber optics network.\n\nThe NMS in this use case can be locally installed on the device but may be running on a different device within the same network, or is a RDPS.\n\nInitial secret provisioning takes place during device initialization.\nA factory reset clears the existing state and restarts the discovery and provisioning process.\n\nThe managed elements can actively send metrics to the NMS which can serve multiple elements in the same network.\nThe managed elements can be enabled for DHCP and DNS caching services, and further services including remote connectivity options like a VPN.\n\nMetrics from the managed elements within the home network can be forwarded to the NMS, where the user can perceive these metrics and control the configuration of each managed element.\nIn many deployments, the NMS provides actual configuration control and visualization of the collected metric data with an additional service or alternate piece of software.\nThat is mostly a browser, but sometimes also other possibilities are deployed, such as a command-line interface.\n\n* Goal: Manage network configuration for a small number of home devices\n* Examples: Home network manager, mesh network management\n* Function: Connect home devices to the local network and to the public network\n* Network connectivity: Filtered private network\n\n**Table 4.6.1-1: UC-1-HOME classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | Medium |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Low |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | Low |\n| RF-ADMIN | Administration skill | High |"},{"id":"UC-2-ENTER-S","title":"Enterprise network (small — UC-2-ENTER-S)","description":"A typical enterprise or office network has multiple service requesting users connecting simultaneously to a shared infrastructure.\n\nInfrastructure may include multiple sites connected through a variety of technologies, including but not limited to: public networks, dedicated routing infrastructure like IP-MPLS-tunnel, massive-scale computing and storage systems via data center (cloud systems), or third party service providers, or 5G slicing.\nAn office network also typically operates for long periods, developing layered history of past versions and functions.\n\nWith modern remote working expectations, enterprise networks almost always include remote connectivity options, such as VPNs, that enable remote users to connect to the office network and work with the subset of curated services through a shared intranet environment.\n\nUser identity verification, authorisation, and the maintenance of a user is needed for each such intranet service or environment.\nThis identity pool can be local for the service, shared within the same intranet, or provided as a service outside of the network context.\nIn office environments, larger identity pools provide redundancy, but also complicate the administration of credentials, and reduce response time when credentials are rotated, such as when they are leaked and misused.\n\nWhile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users.\nA contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services.\nIdPs may be part of an NMS or separate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS.\nIn all varieties the nature of the IdP deployed to the network is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration method or IdP technique.\n\nAs the importance of the operational context rises, so does the level of accuracy needed to securely manage identity.\nA larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.\n\nThe increase in size and complexity contribute to increasing multiple risks that require more elaborate management structures.\nWhile many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.\n\nAdditionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data.\nThe type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS need to ensure that the system has the features, hardware, and security to match operational needs.\n\nThe use-cases **UC-2-ENTER-S**, **UC-2-ENTER-M** and **UC-2-ENTER-L** reflects the size of the enterprise.\n\n**Table 4.6.2-1: UC-2-ENTER-S classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Low |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | Low |\n| RF-ADMIN | Administration skill | High |\n\n**Table 4.6.2-2: UC-2-ENTER-M classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Medium |\n\n**Table 4.6.2-3: UC-2-ENTER-L classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-2-ENTER-M","title":"Enterprise network (medium — UC-2-ENTER-M)","description":"A typical enterprise or office network has multiple service requesting users connecting simultaneously to a shared infrastructure.\n\nInfrastructure may include multiple sites connected through a variety of technologies, including but not limited to: public networks, dedicated routing infrastructure like IP-MPLS-tunnel, massive-scale computing and storage systems via data center (cloud systems), or third party service providers, or 5G slicing.\nAn office network also typically operates for long periods, developing layered history of past versions and functions.\n\nWith modern remote working expectations, enterprise networks almost always include remote connectivity options, such as VPNs, that enable remote users to connect to the office network and work with the subset of curated services through a shared intranet environment.\n\nUser identity verification, authorisation, and the maintenance of a user is needed for each such intranet service or environment.\nThis identity pool can be local for the service, shared within the same intranet, or provided as a service outside of the network context.\nIn office environments, larger identity pools provide redundancy, but also complicate the administration of credentials, and reduce response time when credentials are rotated, such as when they are leaked and misused.\n\nWhile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users.\nA contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services.\nIdPs may be part of an NMS or separate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS.\nIn all varieties the nature of the IdP deployed to the network is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration method or IdP technique.\n\nAs the importance of the operational context rises, so does the level of accuracy needed to securely manage identity.\nA larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.\n\nThe increase in size and complexity contribute to increasing multiple risks that require more elaborate management structures.\nWhile many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.\n\nAdditionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data.\nThe type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS need to ensure that the system has the features, hardware, and security to match operational needs.\n\nThe use-cases **UC-2-ENTER-S**, **UC-2-ENTER-M** and **UC-2-ENTER-L** reflects the size of the enterprise.\n\n**Table 4.6.2-1: UC-2-ENTER-S classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Low |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | Low |\n| RF-ADMIN | Administration skill | High |\n\n**Table 4.6.2-2: UC-2-ENTER-M classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Medium |\n\n**Table 4.6.2-3: UC-2-ENTER-L classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-2-ENTER-L","title":"Enterprise network (large — UC-2-ENTER-L)","description":"A typical enterprise or office network has multiple service requesting users connecting simultaneously to a shared infrastructure.\n\nInfrastructure may include multiple sites connected through a variety of technologies, including but not limited to: public networks, dedicated routing infrastructure like IP-MPLS-tunnel, massive-scale computing and storage systems via data center (cloud systems), or third party service providers, or 5G slicing.\nAn office network also typically operates for long periods, developing layered history of past versions and functions.\n\nWith modern remote working expectations, enterprise networks almost always include remote connectivity options, such as VPNs, that enable remote users to connect to the office network and work with the subset of curated services through a shared intranet environment.\n\nUser identity verification, authorisation, and the maintenance of a user is needed for each such intranet service or environment.\nThis identity pool can be local for the service, shared within the same intranet, or provided as a service outside of the network context.\nIn office environments, larger identity pools provide redundancy, but also complicate the administration of credentials, and reduce response time when credentials are rotated, such as when they are leaked and misused.\n\nWhile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users.\nA contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services.\nIdPs may be part of an NMS or separate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS.\nIn all varieties the nature of the IdP deployed to the network is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration method or IdP technique.\n\nAs the importance of the operational context rises, so does the level of accuracy needed to securely manage identity.\nA larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.\n\nThe increase in size and complexity contribute to increasing multiple risks that require more elaborate management structures.\nWhile many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.\n\nAdditionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data.\nThe type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS need to ensure that the system has the features, hardware, and security to match operational needs.\n\nThe use-cases **UC-2-ENTER-S**, **UC-2-ENTER-M** and **UC-2-ENTER-L** reflects the size of the enterprise.\n\n**Table 4.6.2-1: UC-2-ENTER-S classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Low |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | Low |\n| RF-ADMIN | Administration skill | High |\n\n**Table 4.6.2-2: UC-2-ENTER-M classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Medium |\n\n**Table 4.6.2-3: UC-2-ENTER-L classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-3-TELCO","title":"Telecommunications network","description":"A telecommunications network resembles an enterprise network, with the obvious added complexity throughout.\nThe telecommunications NMS will handle a greater load, including more users, devices, and identities.\nIdentity providers (IdPs) are often used to create segmentation and redundancy, and the network uses its routers and switches as base stations serving thousands of users simultaneously.\n\nTelecommunications networks are modelled by division into northbound and southbound abstraction levels or descriptors, where southbound describes traffic from the NMS and hardware controlled by the network.\nNorthbound traffic comes from lower layers of the network such as routers and switches and from the applications and users.\nServices supporting the telecommunications network, both internal and third party, are described as eastbound or westbound, depending on the objectives of the modelled architecture.\nIn the above figure, SIEM is an example service that is adjacent to the NMS, and is often used in modern deployments.\n\nIn telecommunications deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares its own certificate authority (CA) or authorities deployed to the managed machines within the network.\nThe number of these managed machines, number of CA's, and how the CA's are used is dependent on the design of the network.\nAlternatively, even at telecommunications scale, NMS can even provide its own certificates and form an independent and segregated trust domain.\n\n* Goal: Manage telecommunications infrastructure\n* Examples: National phone and data telecommunications provider, virtual telco\n* Function: Manage network topology and device configuration\n* Network connectivity: Public\n\n**Table 4.6.3-1: UC-3-TELCO classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | High |\n| RF-COMPLEX_FUN | Complexity of functions | High |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | High |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-4-SDN","title":"Logical network deployment without physical hardware","description":"A traditional simple network design has a single device listening on incoming connections from a public network facing port and allows selected traffic to pass through to subnets behind the device.\nA mesh network can be a set of these devices, physical or virtual, where multiple subnetworks are interconnected together, and the routing design is many-to-many instead of point-to-point.\nWhile it is often possible to manage the individual node configuration, and the authentication keys between the links, by hand, the configuration management becomes complex and error prone quite fast.\n\nMesh network routing can be made more accurate, if the services are listed as routing targets, and the subjects who would like to have connectivity to those targets are identified.\nCombining the known locations of services and subjects connectivity grants, a custom routing table can be calculated for each subject.\nThis custom routing table can be enforced on the network side by an added layer of control, that either provisions configuration changes to connected nodes firewalls, or provides other mechanisms to assert the authority of the connection.\n\n**Table 4.6.4-1: UC-4-SDN classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | High |\n| RF-COMPLEX_FUN | Complexity of functions | High |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | High |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-5-HYBRID","title":"Physical network deployment with RDPS","description":"When almost everything can be software, the minimum still remains: the user needs to have some form of User Equipment to be able to connect.\nThis Network Interface can be a radio in the cellphone, a WiFi Access Point in the living room, or a router with SFP+ ports serving the local datacenter.\nHow much the network structure has autonomy on control and local network routing the device has can be modeled in function of how much RDPS is involved in the design.\n\nInter-networking architecture with RDPS participating in the routing transforms a physical deployment into a logical deployment in the convergence point, which is the device installed into the site.\n\nIn the figure above, the maximum RDPS involvement, the network handles the connection like a hot potato: it is handed over to the RDPS immediately or as soon as possible.\nThe local network is used as little as possible, and even the home office routing can take a detour through RDPS in order to provide an auditable trail of how the remote working employee is using the network.\n\nTechnologies like 5G slicing, enable for the flexibility of the closest point of return in respect to re-routing back to the user network: It could be the nearest base station or even the a forward proxy server server on the other side of the world.\nThese two scenarios result in a different user experience where the latter would most likely show as slow and unresponsive service, but both are valid designs that can be deployed.\n\nMedium RDPS involvement is a common hybrid setup, where the company already has older assets that are grown into the enterprise, and are kept around as there is little or no need to change the infrastructure.\nPart of the network design is created with virtual assets, that could be the new IT infrastructure for the latest acquired company, while the still significant portion of networking assets are tied to the headquarters datacenter.\n\nControl structures are different, device management strategies are varying, and even the physicality can extend to multiple nations.\nThe balance of owned assets and bought services is often selected due to ease of deployment, while the partial reliance on headquarters datacenter offers resilience towards major outages in the connectivity.\nThe end result might not be optimal, but often acceptable in the eyes of company risk management.\n\nIn a minimal RDPS involvement, all of the relevant infrastructure is not fulfilling the RDPS definition, and can be deployed to an underground infrastructure spanning multiple locations for example.\nInterconnection between the sites is either owned, or leased from a provider.\n\nSome links can be through dedicated IP/MPLS tunnels, while some could be implemented through public connectivity with VPN tunnels. The RDPS mainly serves only update packages to the NMS, validates licensing if needed and can collect usage statistics for product development purposes.\n\nWhile system updates are critical for the product, the installation is fully independent and no functionality is relying on the RDPS connectivity. The system updates can be delivered with a removable medium, if no connectivity to software repositories is available.\n\n**Table 4.6.5-1: UC-5-HYBRID classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | High |\n| RF-COMPLEX_FUN | Complexity of functions | High |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | High |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-6-IOT","title":"IoT network with monitoring data collection","description":"Contemporary advancements in microcontroller features and related platforms used to build IoT devices blur the distinction between a simple device and a complex computation node, often reducing the description of a device as \"IoT\" to a branding decision from the manufacturer.\n\nAn IoT network is a network of devices, each of which almost always has limited computational capabilities and consumes a low amount of power.\nThe exact purpose of these devices varies, but they are all connected to an NMS, and often to each other and to an IoT business logic, which may be a RDPS.\nThe main focus of an IoT network is almost always data collection, and the NMS in this use case usually visualises the collected data metrics and provides them to the end-user.\nThe NMS-analysis of the data metrics can be automated, including triggering warnings, alarms, or even taking actions based on discovered abnormal events.\nThe IoT NMS also collects the meta traffic data and management related data from networked devices, and sometimes forwards it to other systems for processing and storage.\nIt is not uncommon that the business logic and the NMS in this use case are offered together as a single product, providing a full networking ecosystem.\n\nEven when data collection is the main focus of an IoT network, the network and NMS functions of this use case are not limited to it.\nAn IoT network NMS also usually visualises the collected data metrics and provides them to the end-user while offering users ways to make actions based on the data provided.\nThe NMS analysis of collected metrics can also be automated, including triggering warnings and alarms. In some implementations the NMS may even take actions based on its discovery of abnormal events.\n\nBeyond collecting data from connected devices and preparing data metrics, the NMS controls the configuration of the connected devices, providing two minimum security functions:\n\n1. Establishes trust between the system and the devices.\n2. Maintain an inventory of devices that are part of the managed network.\n\n* Goal: Manage large fleet of IoT devices\n* Examples: NMS for network-connected washing machines or toasters\n* Function: Manage network configuration for a large fleet of appliances\n* Network connectivity: Public network\n\n**Table 4.6.6-1: UC-6-IOT classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Medium |"},{"id":"UC-7-ICT","title":"ICT Network Elements","description":"The ICT Element management is an enterprise-focused system to control and manage the configuration of the connected enterprise application on the ICT Elements.\nAn ICT Element can encompass anything from routers, modems, switches up to mobile devices, tablets, smart phones, laptops, desktop PCs to servers.\nThe use case describes a system that provides centralised governance of the enterprise application running on the ICT Elements within the scope of an organization.\n\nICT device management is in general subject to enterprises or larger organizations that equip their employees with the essential ICT elements they work with.\nThe users usually do not have full administration rights and are restricted to the application level to manage personal look and feel.\n\nDue to the broad functionality of the ICT Elements, the controls need also to be strongly extended, compared with the IoT use case, to ensure the centralised governance by the enterprise for the related application is maintained.\nThat can be characterized as follows:\n\n* Provision of preconfigured ICT elements or enterprise applications to the employees\n* centralised ICT element or enterprise application update management\n* Trust establishment between the ICT elements, or the enterprise application, other communicating entities and the NMS, by the NMS\n* The NMS controls and sets the ICT element and the enterprise application configuration settings to manage:\n * The connectivity of the managed ICT elements and the enterprise application among each other, like VPN configuration\n * The formation of user groups with their management in relation with dedicated access control management\n* Control software installation, reporting and individual permission on the ICT element respectively enterprise application\n* Backup and recovery controls for either the ICT element or the enterprise application\n* ICT Element respectively enterprise application status tracking and compliance control to enterprise guidelines and safeguards\n* Remote control of the ICT element or the enterprise application features if present\n\nThe employees have only those administration rights the central administration granted before and which the NMS configures according to the enterprise rules.\nWith that the ICT elements are an integral part of the business logic and enterprise processes running in the background.\n\nRestrictions in the central governance are only present with relation to GDPR and locally applicable employee protection regulations for the enterprise owned parts.\nIn all known cases, for the enterprise owned parts, connectivity and its execution of centrally controlled software are subject of the central administration.\nThe NMS supports the central administration in their governance.\nThe NMS operating the configuration of the enterprise owned parts usually also ensures the enforcement of enterprise guidelines, restricts user actions, and prevents unallowed connections to protect the enterprise from data disclosure by blocking interfaces and setting restrictions for applications.\n\nThe mobile device management need not be mismatched with the management functions that are subject to the radio network management functionality that ensures connectivity and performance with the RAN.\nThese requirements are handled with the EN 304 642 network functions [i.17\\].\n\nICT Elements can have four managing entities at the same time as illustrated in the figure above:\n\n1. The ICT element enterprise application management and the ICT Element owner decide about the enterprise application installations the employee needs.\n The installation configures the ICT element when the enterprise application is launched, and that sets the user and the enterprise application rights.\n The NMS can support the installation as well as the configurations.\n The NMS controlling the enterprise application is usually able to track the ICT element when the enterprise application runs according to the enterprise rules.\n That can also include support for automated application updates.\n2. For a radio-connected ICT Element, the central radio network- or telecom's administration ensures connectivity and performance of the ICT element in connection to the RAN.\n A part of the RAN settings is static and provided by the (e)SIM, another is dynamic and subject to the concrete ICT Element situation in connection to the RAN.\n The ICT Element’s operating system update is completely separated from the enterprise application and operates directly with the NMS of the operating system manufacturer.\n The enterprise application runs on a higher level.\n The radio-connected ICT Element can operate an automated update service in pull or push ways, the NMS of the operating system manufacturer can support this.\n3. The similar holds for wired-connected ICT Elements but without the complexity of the RAN.\n The central telecom's administration or CSP ensures connectivity and performance of the ICT element in the wired connection.\n The ICT Element’s operating system update is completely separated from the enterprise application and operates directly with the NMS of the operating system manufacturer.\n The enterprise application runs on a higher level.\n The wired-connected ICT Element can operate an automated update service in pull or push ways, the NMS of the operating system manufacturer can support this.\n4. The mobile manufacturer can update the ICT elements to upgrade, update or mitigate vulnerabilities on the ICT element excluding applications that were installed after delivery.\n This manufacturer action can take various ways or methods, also push and pull style by the mobile ICT element itself.\n Usually, updates from the ICT Element manufacturer, such as firmware, use the way via the operating system manufacturer.\n In all cases, the owner of the mobile ICT element decides.\n\nIn all cases, application rights are managed and controlled, as the device management remains subject of the enterprise NMS, as the ICT elements are and remain in ownership of the enterprise.\n\n**Table 4.6.7-1: UC-7-ICT classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | High |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | Medium |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Medium |"},{"id":"UC-8-FLEET","title":"Fleet management","description":"In this use case the NMS manages the software lifecycle and configuration state of a fleet of general-purpose hosts — typically Linux servers, but also workstations or virtual machines — rather than their network traffic.\nThe product's role is to keep the managed hosts in a known, consistent, and compliant software state.\nThis is the domain of dedicated configuration and systems management products, for example software repository and patch managers, configuration-as-code controllers, and provisioning systems.\n\nThe NMS in this use case implements the [ICT device management](#414-ict-device-management) functions and draws on [ecosystem management](#413-ecosystem-management) for software delivery.\nIts characteristic functions are:\n\n* Package, patch, and content/channel management, including mirroring software content from an upstream source and curating it into controlled channels before delivery to the managed hosts.\n* Configuration management, where the desired state of a host is declared centrally and enforced on the host, often through an agent running on the host.\n* Provisioning of hosts, including operating system installation and initial configuration.\n* Inventory of installed software and hardware for each managed host, as described in [4.2.4.2 Inventory management](#4242-inventory-management).\n* Compliance and audit, where hosts are evaluated against a security baseline and deviations are reported.\n* Delivery of configuration and software to hosts in a push model (initiated by the NMS) or a pull model (requested by the host), in both cases with host-side verification of the integrity and authenticity of the delivered content, as described in [4.2.4.3 Device management](#4243-device-management).\n\nManaged hosts typically run an agent that registers with the NMS during enrolment.\nTrust between the NMS and each host is established at enrolment, as described in [4.3.4.4 Trust initialisation](#4344-trust-initialisation), and is thereafter used to authenticate the host and to deliver configuration, content, and commands.\nThe connectivity between the NMS and the managed hosts is, in this use case, usually provided by the surrounding network and is not controlled by the product, as described for [devices using provided connectivity](#4214-devices-using-provided-connectivity).\n\nThe NMS can be deployed as a single instance for a small estate, or scaled with intermediate proxies or hubs that cache content and relay commands to hosts in remote sites or segmented networks, following the [distributed deployment](#421-network-architecture) pattern.\nThe upstream software content source — and, depending on the product, subscription, licensing, or usage reporting — is commonly external to the product and is then a [remote data processing solution](#44-distribution-of-security-functions), to which the provisions of [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) apply.\n\nBecause the NMS holds privileged, often root-equivalent, control over the installed software and configuration of every managed host, a compromise of the NMS or of its content delivery path has an impact radius potentially spanning the entire fleet.\nThe integrity and authenticity of delivered content and configuration, the strength of host enrolment and authentication, and the isolation of the management plane are therefore the dominant risk factors in this use case.\n\n> NOTE: This use case concerns the system that manages the hosts. The intrinsic security of the operating systems running on the managed hosts is addressed by ETSI EN 304 626 [i.15\\].\n\n* Goal: Manage network configuration in a controlled homogenous fleet of devices\n* Examples: Servers in a data center, phones in a test lab\n* Function: Configure network of managed elements, maintain simple network topology\n* Network connectivity: Filtered private\n\n**Table 4.6.8-1: UC-8-FLEET classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | Medium |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | High |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-9-RESEARCH","title":"Research NMS","description":"* Goal: Provide minimum functionality for research or training\n* Examples: Simple NMS for a collection of containers used for research or training\n* Function: Configure network on simulated managed elements or operate a laboratory\n* Network connectivity: Isolated private network\n\n**Table 4.6.9-1: UC-9-RESEARCH classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | Low |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | Low |\n| RF-SENS_FUN | Sensitivity of functions | Low |\n| RF-NUM | Number of elements | Low |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-10-AIRGAP","title":"Airgapped secure facility","description":"* Goal: Control network configuration in an isolated network\n* Examples: Malware research lab, highly sensitive software development facility\n* Function: Configure devices and network configuration in highly controlled environment\n* Network connectivity: Isolated private\n\n**Table 4.6.10-1: UC-10-AIRGAP classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | Low |\n| RF-COMPLEX_CONF | Complexity of configuration | Low |\n| RF-COMPLEX_FUN | Complexity of functions | Low |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | High |\n| RF-NUM | Number of elements | High |\n| RF-ADMIN | Administration skill | Low |"},{"id":"UC-11-WATER","title":"Management of distributed infrastructure","description":"* Goal: Manage connectivity to widely scattered infrastructure devices of an important entity.\n* Examples: Network configuration of water pumps and waste management entities.\n* Function: Configure network of managed elements with occasional network topology changes.\n* Network connectivity: Public\n\n**Table 4.6.11-1: UC-11-WATER classification**\n\n| ID | Risk factor | Classification |\n| --------------- | --------------------------- | -------------- |\n| RF-ACC_ASSETS | Accessibility to product | Medium |\n| RF-COMPLEX_CONF | Complexity of configuration | Medium |\n| RF-COMPLEX_FUN | Complexity of functions | Medium |\n| RF-SENS_ASSETS | Sensitivity of elements | High |\n| RF-SENS_FUN | Sensitivity of functions | Medium |\n| RF-NUM | Number of elements | Medium |\n| RF-ADMIN | Administration skill | Medium |"}],"craMap":[{"craRef":"Annex I, Part 1, (1)","clauses":"5"},{"craRef":"Annex I, Part 1, (2)(a)","clauses":"5.3"},{"craRef":"Annex I, Part 1, (2)(b)","clauses":"5.4"},{"craRef":"Annex I, Part 1, (2)(c)","clauses":"5.5"},{"craRef":"Annex I, Part 1, (2)(d)","clauses":"5.6"},{"craRef":"Annex I, Part 1, (2)(e)","clauses":"5.7"},{"craRef":"Annex I, Part 1, (2)(f)","clauses":"5.8"},{"craRef":"Annex I, Part 1, (2)(g)","clauses":"5.9"},{"craRef":"Annex I, Part 1, (2)(h)","clauses":"5.10"},{"craRef":"Annex I, Part 1, (2)(i)","clauses":"5.11"},{"craRef":"Annex I, Part 1, (2)(j)","clauses":"5.12"},{"craRef":"Annex I, Part 1, (2)(k)","clauses":"5.13"},{"craRef":"Annex I, Part 1, (2)(l)","clauses":"5.14"},{"craRef":"Annex I, Part 1, (2)(m)","clauses":"5.15"}],"topics":[{"clause":"5.2","title":"Appropriate level of cybersecurity","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (1).\n\nFor **low** risk:\n\nFor **medium** risk:\n\n* everything in low risk, and\n\nFor **high** risk:\n\n* everything in low risk, and\n* everything in medium risk, and\n\n> NOTE: Modern software design can rarely ignore the impact of the changes to other components.","addressedBy":[],"otherRequirements":[],"mappingTable":{"CYB_GENERAL-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CYB_GENERAL-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CYB_GENERAL-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CYB_GENERAL-4":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"CYB_GENERAL-5":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"CYB_GENERAL-6":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"CYB_GENERAL-7":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"CYB_OPS-8":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CYB_OPS-9":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CYB_OPS-10":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"CYB_GENERAL-1","requirement":"The product shall define whether a service is completely fulfilled by the product itself.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_GENERAL, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Product functionalities, interface operations and interactions with external services are documented and understood.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation;\n2. Cross-reference the product documentation to the external system operations;\n3. Monitor the network traffic and capture all targets the system is trying to initiate a connection with;\n4. Operate at least a sample selection of the product’s most comprehensive or complex core functions for the managing of the external elements to verify its functional correctness;","verdict":"1. Pass if product dependencies or external systems are named and their purpose and provisions are described\n2. and the services or external systems are clearly expressed as part of the architecture description\n3. and the monitored network traffic targets match the documentation.\n4. and the sample selection of core functions operated and resulted in what is claimed.\n5. Fail otherwise.","evidence":"* Screenshots of the conduct and results, before and after operation of the core functions.\n* References to the documentation sections.\n* Listing of discovered targets and an explanation of those targets.","guidance":""}},{"id":"CYB_GENERAL-2","requirement":"The product shall describe the external services and systems that are required for product operation.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_GENERAL, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Product dependencies to external services and systems are documented and understood.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation;\n2. Cross-reference the product documentation to the external system operations;\n3. Monitor the network traffic and capture all targets the system is trying to initiate a connection with.","verdict":"1. Pass if product dependencies or external systems are named and their purpose and provisions are described\n2. and the services or external systems are clearly expressed as part of the architecture description\n3. and the monitored network traffic targets match the documentation.\n4. Fail otherwise.","evidence":"* References to the documentation sections.\n* Listing of discovered targets and an explanation of those targets.","guidance":""}},{"id":"CYB_GENERAL-3","requirement":"The product shall describe the dependencies to Operating System security capabilities.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_GENERAL, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Dependencies to OS capabilities are documented and understood.","preparation":"None","activities":"1. Study the technical documentation.","verdict":"1. Pass if important and essential OS services and concepts are named\n1. and their usage to run the application workload is clearly expressed as part of the architecture description.\n1. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"CYB_GENERAL-4","requirement":"In the context of key management and accepting new elements to the management context the product shall support:\n 1. initialisation of trust in a greenfield deployment, and in the connected element management;\n 2. accepting managed elements into the network based on that trust;\n 3. key rotation and replacement of all relevant cryptographic keys after trust has been established.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_GENERAL, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"New elements added into the management pool are able to adopt the trust initialised with the system.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have a not yet and not enrolled managed element available for testing","activities":"1. Investigate how the system initialises trust;\n2. Perform necessary actions defined in the technical documentation;\n3. Join the new element into the product and make it a managed element;\n4. Rotate the keys used in previous steps;\n5. Repeat in all connections where such trust is used.","verdict":"1. Pass, all tests pass without issues\n2. and they keys are changed to the new ones in a way that survives interruptions.\n3. Fail otherwise.","evidence":"* References to documentation sections.","guidance":""}},{"id":"CYB_GENERAL-5","requirement":"The product shall provide functionality to replace user accessible and controlled cryptographic keys.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set CYB_GENERAL, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"To understand and to be able to take control over the keys used in confidentiality and integrity protection.","preparation":"None","activities":"1. Study the technical documentation.\n2. Cross reference to the architectural description of how the encryption is used in different parts of the system.","verdict":"1. Pass, if the system user has an ability to change user controllable cryptographic keys in the system except the ones that are reasonably made immutable.\n2. Fail otherwise.","evidence":"* References to documentation sections.","guidance":""}},{"id":"CYB_GENERAL-6","requirement":"The product shall clearly indicate the purpose and usage of keys that are not user accessible, where present.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set CYB_GENERAL, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"To understand and to distinguish user accessible and manufacturer keys.","preparation":"None","activities":"1. Study the technical documentation.\n2. Cross reference to the architectural description whether user accessible and manufacturer keys are declared.","verdict":"1. Pass, if the technical documentation matches with the user accessible keys in the product installation\n2. and the reasoning used to justify the used non-accessible keys is reasonable in the context of the product's foreseeable and intended use.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CYB_GENERAL-7","requirement":"The product shall record all system time drift corrections as monitoring events.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set CYB_GENERAL, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: high; UC-2-ENTER-L: high; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: high; UC-8-FLEET: medium; UC-9-RESEARCH: low; UC-10-AIRGAP: low; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Where multiple monitoring targets are operating, all shall have consistent times. Any received alarm of a drift or asynchrony correction shall be accurately documented and notification provided to administrator.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have a system node in operation;\n3. Have a managed element in operation.","activities":"1. Set the node and the chosen managed element to a wrong time that is off by at least an hour;\n2. Set connected system service to a wrong time that deviates from real time by at least one hour.","verdict":"1. Pass, if the product detects the drift correction\n2. and creates a notification about the event.\n3. Fail otherwise.","evidence":"* System notification from the logs.","guidance":""}},{"id":"CYB_OPS-8","requirement":"The product shall clearly indicate deployment, update, and upgrade instructions expected from the operational environment (OE).","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_OPS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product user is able to meet the expectations of the product with the operational environment.","preparation":"1. Study the technical documentation.","activities":"1. Cross-reference the provided deployment instructions to describe target environment design guidelines.","verdict":"1. Pass, if the deployment, update and upgrade instructions are aligned with the target environment functionalities.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CYB_OPS-9","requirement":"The product shall describe the traffic related to the product operation, including at minimum, configuration, metrics, and API access, that is addressed as Application-level traffic as per RFC 1122 [2\\].","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CYB_OPS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product user understands the different kinds of connectivity the product can use.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Dump all relevant connectivity information from the product;\n2. Cross-reference to the technical documentation;\n3. Identify potential low level protocol usage that is not able to operate with adequate confidentiality.","verdict":"1. Pass, if no low level protocol usage is detected\n2. and the technical documentation matches the implementation.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CYB_OPS-10","requirement":"The product shall satisfy the applicable remote data processing solutions requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to the subset of products that rely on a remote data processing solution (RDPS) for the provision or support of one or more product functions.\n\nRequirement set CYB_OPS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":null}]},{"clause":"5.3","title":"No known exploitable vulnerabilities","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (a).\n\n> NOTE: A container hosting the product always has an operating system.\n\n> NOTE: An exploitable vulnerability's transition from “unknown” to “known” may be by its publication to the EU Vulnerability Database, an industry-specific vulnerability database, or direct notification to the manufacturer via its own vulnerability reporting process.","addressedBy":[],"otherRequirements":[],"mappingTable":{"KEV_EXPLOIT-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"KEV_EXPLOIT-1","requirement":"The product shall:\n 1. have no known exploitable vulnerabilities, or\n 2. have no known exploitable vulnerabilities that were reported to within the previous 14 days, or the time period permitted before public disclosure as described in the vulnerability handling procedure for the product, or\n 3. have no known exploitable vulnerabilities that do not have associated publicly-available documentation explaining the risk and how that risk has been mitigated.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set KEV_EXPLOIT: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Automatic or other vulnerability scans at the assessment day prove that the product is without known exploitable vulnerabilities that are not addressed and mitigated.\n\nVerify that:\n1. Known exploitable vulnerabilities affecting the product are identified and the scanning delivered no additional results.\n2. For each identified known exploitable vulnerability, one of the following applies:\n * the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or\n * specific user guidance is provided to prevent exploitation.\n3. No known exploitable vulnerability remains in the product without one of the above justifications.","preparation":"* Product documentation identifying components contained in the product (components may include software, firmware, or hardware components, as applicable).\n* Component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available.\n* Access to the product, or to relevant components such as binaries, packages, images, firmware, containers, or file systems, sufficient to perform vulnerability scanning where technically feasible.\n* Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product.\n* Access to recognized public vulnerability sources:\n * Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD) and relevant vendor advisories;\n * Complementary sources that may support identification of relevant vulnerabilities, where relevant, for example technical research papers, conference papers and other publicly available security research.","activities":"1. Review the product documentation, component inventory, bill of materials, or equivalent information to identify the components contained in the product (which may include software, firmware, or hardware components, as applicable) and their relevant versions or patch levels, where available.\n2. Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting the product.\n3. Assess, in accordance with prEN 40000-1-3 [i.6], the vulnerabilities identified through correlation of scanning results, product identification information, vendor advisories, and recognized public vulnerability sources.\n4. For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product:\n5. Where the treatment of an identified known exploitable vulnerability relies on user guidance, review the user guidance and verify that it specifically addresses the conditions to prevent exploitation.\n6. Verify that no identified known exploitable vulnerability affecting the product remains without:\n * a vulnerability assessment demonstrating non-exploitability in the product; or\n * specific required user guidance to prevent exploitation.","verdict":"1. Pass, if no known exploitable vulnerabilities affecting the product are identified,\n2. and each of them is identified and covered either by a vulnerability assessment, demonstrating non‑exploitability in the product, or by specific user guidance preventing exploitation.\n3. Fail otherwise.","evidence":"* Vulnerability scanning results, including the tools and vulnerability databases used with snapshot date information.\n* Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment.\n* Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3 [i.6].\n* Product user guidance relied upon to prevent exploitation, where applicable.","guidance":""}}]},{"clause":"5.4","title":"Secure by default configuration","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (b).\n\n> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) provides for an applicability exception to the secure configuration by default Essential Cybersecurity Requirement in the scenario that the manufacturer and business user have an agreement in relation to a tailor-made product with digital elements. That exception does not exempt products from the requirement to provide a method to reset to a secure by default configuration.","addressedBy":[],"otherRequirements":[],"mappingTable":{"SBD_TECH-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SBD_TECH-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SBD_TECH-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"SBD_TECH-1","requirement":"The product shall:\n 1. implement accepted cryptographic methods as described in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment) on all interfaces that are available or reachable outside of localhost within the local processes, and\n 2. by default only enable cryptographic mechanisms listed in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment)","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SBD_TECH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The data on the product are cryptographically protected.","preparation":"None","activities":"1. Study the technical documentation.\n2. Identify the structures where data is transferred as described in the requirement.\n3. Study the deployment guidance and the protocols used.\n4. Compare the cryptographic implementation of the product and of the technical documentation.","verdict":"1. Pass, if the data flow and transmission are identifiable from the technical documentation\n2. and testing the implementation of interfaces matches the documentation\n3. and the interfaces deploy the protocols operating the cryptographic means protecting the data in accoradance to Annex K.\n4. Fail otherwise.","evidence":"1. Listing of tested interfaces and the protocol replies that show that cryptography as of Annex K is used.\n2. Listing of the interfaces, their deployed protocols with the invoked cryptographic means.","guidance":""}},{"id":"SBD_TECH-2","requirement":"The product shall:\n 1. exclusively use interoperability-based cryptographic mechanisms as described in [clause K.4](k.4-interoperability-based-cryptographic-mechanisms), and\n 2. provide a user notification or other informative function when using such methods, and\n 3. inform the user which component requires the backwards compatible mechanism, and\n 4. indicate an upgrade path to using more secure cryptography when available.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to the subset of products that provide backward compatibility with cryptographic algorithms other than those listed in [clause K.3](#k.3-acm-extended-cryptographic-mechanisms).\n\nRequirement set SBD_TECH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The system user has the ability to leave the default configuration in order to enable for backward compatibility.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Study the technical documentation;\n2. Enable a by default disabled, backward compatible protocol or other cryptographic implementation.","verdict":"1. Pass, if the listed requirements are implemented when backward compatibility is offered.\n2. Pass, if no backward compatibility is offered and the cryptography on the product is state-of-the-art as defined in Annex K.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SBD_TECH-3","requirement":"The product shall provide a method with which to reset to a secure by default setting.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SBD_TECH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The system user has the ability to restore secure default settings.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Make configuration changes that negatively impact overall product cybersecurity.\n2. Use the product function to restore default configuration.","verdict":"1. Pass, if the configuration changes have been reverted to a secure setting and settings unrelated to cybersecurity are unchanged.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}}]},{"clause":"5.5","title":"Security updates","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (c).","addressedBy":[],"otherRequirements":[],"mappingTable":{"SU_UPDATES-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-4":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-5":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-6":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-7":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-8":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-9":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-10":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-11":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-12":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-13":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-14":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"SU_UPDATES-15":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"SU_UPDATES-1","requirement":"The product shall have the ability to receive security updates.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product has functionality to be securely updated.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Provide an update package on the foreseen source.","activities":"1. Either the product notifies the system user after the update package is made available, or, the assessor notifies the administrator about the availability.\n2. Either the product itself or the system user updates the product with the package.\n3. The product writes the event in the log file.","verdict":"1. Pass if the secure update completes successfully\n2. and the log entry is present\n3. and the documentation includes all the required information\n4. and the instructions are noting the custom requirements of the application, if any\n5. and the interfaces connected during the update procedure are known\n6. and the integrity of the content is ensured during the update procedure.\n7. Fail otherwise.","evidence":"1. Documentation of the update package provision and the system user notification\n2. Documentation of the update conduct\n3. Screenshot of the log entry.","guidance":""}},{"id":"SU_UPDATES-2","requirement":"The product shall have independent OS and application update procedures enabling the user to schedule the update following the operational needs and the High Availability targets.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Responsibility of OS level upgrades can be elsewhere outside of the system control. Updates of the product OS and security relevant updates are divorced and can be scheduled according to the operational needs and the application is designed to tolerate this behavior without compromising the service availability.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation about the separation of security relevant updates.","verdict":"1. Pass if cross referencing OS and Application update instructions makes it possible to maintain High Availability requirements defined in the technical documentation.\n2. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"SU_UPDATES-3","requirement":"The product shall by default attempt to install security updates at the time of first use to address all known exploitable vulnerabilities which were discovered after the product's placement on the market and before first use.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to subset of products that are not updated by the OE.\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"","preparation":"1. Program a test source providing an authentic and integrity correct update package.","activities":"* Operate the test update server.\n* Study the technical documentation.\n* If needed, activate the update mechanism and check whether the mechanism is configurable.\n* Check if the update mechanisms can be configured to check itself for updates, conduct the update on trigger, or run at first use.\n* Configure the update mechanisms with respect to point in time of conduct.\n* Powerup the product to simulate first use","verdict":"* The technical documentation describes the update mechanism in sufficient practical detail to conduct the update.\n* The test update is operated as configured on action, prior, or as part of the first use.\n* The test update was operated as configured with respect to the point of time of conduct.","evidence":"* References to document sections.\n* Screenshots from the update configurations and of the corresponding conducts.","guidance":""}},{"id":"SU_UPDATES-4","requirement":"The product shall verify authenticity and integrity of the update package using a cryptographic signature verification prior to installation.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to subset of products that are not updated by the OE\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The alteration of an update package is detected.","preparation":"1. Study the technical documentation.","activities":"1. Fetch a product update package from upstream source;\n2. Verify the package;\n3. Alter the package;\n4. Verify the package.","verdict":"1. Pass, if package signature is valid and the used signature is implemented according to **CON_CRYPO-1**.**\n2. and alteration of the update package is detected.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-5","requirement":"The product shall maintain a monotonic version counter or equivalent mechanism to prevent installation of updates with an older version.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to subset of products that are not updated by the OE\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Prevent accidental installation of older packages.","preparation":"1. Study the technical documentation.","activities":"1. Ensure update package repository continuous versioning lineage.","verdict":"1. Pass, if there is no out of order version numbering used within the implemented scheme.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-6","requirement":"The product shall provide a mechanism to restore the system to the operational state after a failed update.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product outage time after a failed update is minimised.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Start an update;\n2. Kill the process performing the update or otherwise, from the system side, interrupt the process unexpectedly;\n3. Perform the instructed measures.","verdict":"1. Pass, if the system is able to recover from the test.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-7","requirement":"The product shall provide a way for the system user to postpone or re-schedule the application update.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to the subset of products that operate in an operational environment that allows for postponement or rescheduling of application updates.\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product allows to schedule or postpone updates that meet the high availability needs.","preparation":"1. Study the interface and how scheduling or postponing of an update works.\n2. Study the technical documentation.","activities":"1. Study the interface and how the post-pone of an update works.","verdict":"1. Pass, if the system user controls the point in time the update is made.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-8","requirement":"The product shall require explicit authorization and emit an auditable event containing metadata when intentaional rollback is invoked.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to products that support intentional version rollback.\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Any rollback operation is authorised and generates a log entry.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Check that the user role to operate the rollback is authorised;\n2. Login and perform a rollback to a previous version;\n3. Observe the emitted audit record.","verdict":"1. Pass, if rollback is done successfully\n2. and an audit event is emitted.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-9","requirement":"The product shall automatically recover from a failed update and resume operation if applicable or otherwise achieve a secure state.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product recovers after a failed update either to the operational, or a secure state that cannot be exploited.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Initiate update;\n2. Interrupt the update by killing the active update process.","verdict":"1. Pass, if the system recovers to a functional operational or a secure state.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-10","requirement":"The product shall inform the system user about update availability if applicable.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The system user receives information when a product update is made available.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Study the system and the notification mechanism.","verdict":"1. Pass, if the notification mechanism functions as expected, which is either with on-product mechanism, or verify that there are direct manufacturer-to-system-user notifications on available updates\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-11","requirement":"The product shall track the relevant component versions of the product and the managed elements if applicable.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product can provide a list of the components it is constituted from and provide a list of the managed elements.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Investigate the version information;\n2. Cross‑reference the components to the technical documentation and identify which can be updated and are subject to versioning.","verdict":"1. Pass, if no important components are left out from the versioning.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-12","requirement":"The product shall log start and finish of the update download if applicable.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product user understands when the system is in update operation.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Investigate the system log trail about updates.\n2. Initiate a download if not performed.","verdict":"1. Pass, if the logs show the update package being transferred to the system.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-13","requirement":"The product shall perform an automatic update of the product.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to products that support automatic updates.\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product operates with the latest available updates.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Launch an old version of the product.\n3. Study the technical documentation.","activities":"1. Have an old version of the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation and the logs.","verdict":"1. Pass, if update happens without user interaction.\n2. Fail otherwise.\n\n> NOTE: System time distortion is allowable for testing purposes.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-14","requirement":"The product shall enable automatic updates by default.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to products that has automated update functionality.\n\nRequirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"If the product has automated update functionality, then this functionality is activated by default.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Investigate the configuration options.","verdict":"1. Pass, if automatic updates are turned on by default.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"SU_UPDATES-15","requirement":"The product shall perform an update without impacting the defined availability targets.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set SU_UPDATES: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The update process doesn't decrease the availability of the product.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation.","activities":"1. Investigate the update functionality.\n2. Test the update.","verdict":"1. Pass, if the update strategy used is expected to finish succesfully without impacting the availability of the product,\n2. and, if the update of a layer defined in [4.3.2 Physical/Hardware environment](#432-physicalhardware-environment) doesn't impact the availability of the product.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}}]},{"clause":"5.6","title":"Authentication and access control","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (d).\n\nThese requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.\n\n> NOTE: **AAC_AUTH-2** applicability exclusion for UC-1-HOME is a nessesary tradeof when RF-ADMIN is high.","addressedBy":[],"otherRequirements":[],"mappingTable":{"AAC_AUTH-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-4":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-5":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-6":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-7":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-8":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-9":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-10":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-11":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_AUTH-12":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_MACHINE-13":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"AAC_MACHINE-14":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"AAC_AUTH-1","requirement":"The product shall support identity management through at least one of the following approaches:\n 1. integration of the product into an external state-of-the-art Identity Management System, or\n 2. integration of an external Identity Management System into the product, or\n 3. a dedicated Identity Management module built into the product.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Identity management as basis for authentication is supported.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Study the documented deployment guidance.","verdict":"1. Pass if one of the listed methods is supported.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-2","requirement":"The product shall not allow for default credentials or keys to be used to identify subjects.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement does not apply to tailor-made products, where product user requests changes as per CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (b).\n\nThis requirement does not apply to UC-1-HOME, where the initial password is unique between instances of the product, and is provided to the product user in a confidential manner.\n\nRequirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Any subject receives an individual key, either on board generated or imported.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Study the documented deployment guidance.","verdict":"1. Pass if no predefined secrets or keys are used to identify the first subject.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-3","requirement":"The product shall eliminate default credentials by either:\n 1. generating credentials during the first use; or\n 2. enforcing mandatory credential creation during the initial setup of a new system user or a managed element.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Subject identification is not relying on pre-determined defaults.","preparation":"1. Study the technical documentation how to interact with the system;","activities":"1. Investigate the product how it is take into use.\n2. Take the product in to use for the first time.","verdict":"1. Pass, if the product mechanism doesn't rely on pre-determinted secrets,\n2. and the credential creation is forced as part of the first use.\n3. Fail otherwise.","evidence":"* Screenshots, captures, or console outputs confirming the correct authentication with MFA;\n* Logs from the authentication and rejection events;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;","guidance":""}},{"id":"AAC_AUTH-4","requirement":"The product shall use multi‑factor authentication to authenticate system users.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"System users are identified with multi-factor authentication.","preparation":"1. Study the technical documentation how to interact with the system;","activities":"1. Investigate the multifactor authentication implementation;\n2. Try to access with a wrongly applied authentication method.","verdict":"1. Pass, if MFA is used and is required from the authenticating human user\n2. and if the authentication with the wrongly applied method was rejcted.\n3. Fail otherwise.","evidence":"* Screenshots, captures, or console outputs confirming the correct authentication with MFA;\n* Logs from the authentication and rejection events;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;","guidance":""}},{"id":"AAC_AUTH-5","requirement":"The product shall limit a system user’s session validity duration via a configurable setting that shall initially be limited to a default of, at maximum, one day.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Have an ability to adopt the system users entity context practices.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the product and the documentation.\n2. Check and set the duration of a session to a duration suitable for the assessment.\n3. Launch the session and keep it passive while measuring the time elapsing.","verdict":"1. Pass, if default is set to the required limit and the user has an ability to reconfigure it\n2. and the session gets terminated after reaching the set time and that meets the applied setting\n3. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-6","requirement":"The authorization model shall enforce separation of privileges in a way that minimizes subjects access grants to protected functions within the system.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Authorised users have assigned execution and resource access rights.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the product and the documentation;\n2. Try to execute commands not assigned to the present user role.","verdict":"1. Pass, if the user roles defined or other structures match with the assigned rights\n2. and the command execution beyond the present user role gets rejected.\n3. Fail otherwise.","evidence":"* Screenshots, captures, or console outputs proving the users execute commands and access only those records that are permitted to their role.\n* Evidence from the command rejection.\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;","guidance":""}},{"id":"AAC_AUTH-7","requirement":"The product shall require strong authentication of subjects, services, or integrated components to access privileged interfaces, control functions, and sensitive operations.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"All interfaces, controls and sensitive operations are protected by authorisation.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the product and the documentation\n2. Identify all interfaces that are used to interface with users, other systems or components.","verdict":"1. Pass if authentication and authorisation is performed on discovered interfaces.\n2. Fail otherwise.","evidence":"* List of the tested product user interfaces and assigned evidence of the authentication and authorisation operation and their results.\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-8","requirement":"The product shall protect privileged interfaces with state-of-the-art cryptographic libraries as described in [annex K](#annex-k-normative-generic-cryptographic-requirements-and-assessment).","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The authentication and communication on all product user interfaces is cryptographically appropriately protected.\n\n1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system.","preparation":"","activities":"1. Investigate the product and the documentation;\n2. Identify all interfaces that are used to interface with users, other systems or components;\n3. Check whether each interface deploys a protocol with appropriate cryptography from Annex K.","verdict":"1. Pass if the discovered interface implements cryptography based on Annex K in the default settings.\n2. Fail otherwise.","evidence":"* List of interfaces and their operated protocols with assigned cryptographic methods;\n* Screenshots, captures, or console outputs confirming the matched protocol execution;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-9","requirement":"The product shall report all relevant events related to authorisation including, at minimum:\n 1. successful and unsuccessful use of identity,\n 2. object access,\n 3. policy change,\n 4. privileged function use,\n 5. data access and deletions, and\n 6. data changes and permission changes.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Any event in relation with user authorisation gets a logging record.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. To trigger listed activities:\n 1. Login to a user role that does not have access to the listed activities;\n 2. Try to escalate the authorisation by calling a command not allowed for the present role.","verdict":"1. Pass, if the activity is rejected\n2. and an auditable event is emitted.\n3. Fail otherwise.","evidence":"* Log record from the command rejection\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;","guidance":""}},{"id":"AAC_AUTH-10","requirement":"The product shall explicitly authorise any privileged action before its execution can modify, including, at minimum:\n 1. managed-element configuration\n 2. control-plane behaviour routing or forwarding state\n 3. security policy\n 4. identity or authorisation configuration\n 5. cryptographic trust material\n 6. software state\n 7. availability\n 8. network reachability.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"All privileged actions receive an authorisation before their execution.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Login to a user role;\n2. Try to escalate the authorisation by calling a command not allowed for the present role;\n3. Execute at least listed activities.","verdict":"1. Pass, if the execution is rejected\n2. and an auditable event is emitted for each different activitity.\n3. Fail otherwise.","evidence":"* Evidence like screenshots and logs about login procedure, escalating command call and the product reaction;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;","guidance":""}},{"id":"AAC_AUTH-11","requirement":"The product's authorisation decision shall be bound to, and made available in, auditable event data, including at minimum:\n 1. source of the identity\n 2. the acting identity\n 3. whether natural user or machine user\n 4. role or permission set\n 5. target managed element or elements\n 6. requested operation\n 7. material request parameters\n 8. policy version or rule identifier\n 9. and validity interval.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The authorisation for a privileged action is recorded in the log files.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the system.\n2. Login and trigger a security policy change as privileged action.","verdict":"1. Pass if an auditable event is emitted with the listed information.\n2. Fail otherwise.","evidence":"* Printout of logging records documenting the authorisation permission for the security policy change;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_AUTH-12","requirement":"The product shall prevent the execution of any privileged action when the authorisation decision is absent, expired, inconsistent with current policy or context, or cannot be recorded as an auditable event, except where the action aims to enable or restore auditability of the product.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_AUTH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Any privileged action has received its authorisation prior execution, except the action is to restore the logging functionality.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the system;\n2. Login as privileged user;\n3. Disable intentionally all auditabl event collection systems from outside the product by either:\n 1. making the file based system read only, or\n 2. by disrupting the connectivity to a centralised system\n4. Trigger listed activities.","verdict":"1. Pass, if execution of privileged action fails in the described conditions or audit log records for all the executed actions are not lost and available in the external log storage when operational activity is restored.\n2. Fail otherwise.","evidence":"* Evidence of system about the rejection of the command and that it is not executed;\n* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_MACHINE-13","requirement":"The product shall provide authentication for machine users such as certificates or tokens where a expiration is not undefined or, by default, over a year in the future.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_MACHINE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Within machine-to-machine communications the authentication does not use passwords.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the system;\n2. Setup a communication with a managed element and verify the used authentication method.","verdict":"1. Pass if an alternative to preshared keys or passwords is provided.\n2. Fail otherwise.","evidence":"* Metrics output showing detected system or managed element when setting up a communication channel;\n* Evidence confirming the functionality like:\n * Relevant vendor or design documentation describing the applied measures;\n * Test reports showing the steps performed and results obtained;\n * Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n * Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"AAC_MACHINE-14","requirement":"The product shall minimize access for the machine user to privileged interfaces like APIs.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AAC_MACHINE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The machine user operates with the lowest necessary privileges.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Investigate the system.","verdict":"1. Pass if the machine access credentials do not inherit wider access rights than the purpose of the interaction requires within reasonable limits.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.7","title":"Confidentiality protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (e).\n\n> NOTE: More details for **CON_CRYPTO-3** in ETSI EN 304 642 [i.17]","addressedBy":[],"otherRequirements":[],"mappingTable":{"CON_INGEST-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CON_INGEST-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CON_CRYPTO-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CON_CHANNEL-4":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"CON_CHANNEL-5":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"CON_INGEST-1","requirement":"The product shall protect the confidentially and integrity of the collected network element monitoring data.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CON_INGEST: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The integrity and confidentiality of the ingested data is protected.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation.","activities":"1. Study the monitoring data ingestion:\n 1. The reception and/or querying mechanism\n 2. The ingestion workflow steps\n 3. Intermediate storages used in the processing\n 4. The enrichment and filtering of data ingestion\n 5. The communication between the systems involved in the processing\n2. The storage systems used to serve the data for later use.","verdict":"1. Pass, if means for confidentiality and integrity are effective for the ingested data.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CON_INGEST-2","requirement":"The product shall cryptographically protect relevant data at rest and in transit, including at minimum:\n 1. secrets\n 2. confidential configuration data\n 3. metrics that can expose confidential data","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CON_INGEST: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Relevant data types as listed are cryptographically protected at rest and in tranist.","preparation":"1. Extending the assessment defined in [6.7.1 CON_INGEST-1](#671-con_ingest-1)","activities":"1. Study the listed relevant data handling","verdict":"1. Pass, if the data in rest and in transit follows Annex K guidance with the default configuration.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CON_CRYPTO-3","requirement":"To prevent rollback or downgrade the product shall:\n 1. enforce a monotonic cipher suite policy configuration (or equivalent mechanism);\n 2. preven the re-enabling of deprecated algorithms or the disabling of security checks via a rollback operation without having an explicit logged administrative override in place.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CON_CRYPTO: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Attackers cannot version-rollback, downgrade or shorten key length of the actually deployed cipher suite.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation.","activities":"1. Study the product operation;\n2. Try to rollback to an older cryptographic version.","verdict":"1. Pass, if the listed requirements are implemented\n2. and if the rollback trial is rejected with corresponding log entry.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the rejection of the rollback trial;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"CON_CHANNEL-4","requirement":"The product shall ensure that the secure channel uses cryptographic functions and configuration according to the Annex K.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CON_CHANNEL: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The implementation and operation follows the Agreed Cryptographic Mechanisms specification and the Annex K.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation.\n2. Identify the patterns from architectural documentation where encryption is required.\n3. Study the implementation from the product or from the technical documentation.","verdict":"1. Pass if the documentation describes with enough details how and where the cryptographic features and functions are used,\n2. and handling of data is identified and protected with cryptography as defined in Annex K.\n3. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"CON_CHANNEL-5","requirement":"Endpoints within the product shall cryptographically verify all other endpoints in a secure channel using mutual authentication.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set CON_CHANNEL: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"All communicating entities are mutually authenticated with cryptographic means.","preparation":"None","activities":"1. Study the technical documentation.\n2. Identify the structures where administrative, PII or otherwise privileged information is transferred.\n3. Study the implementation from the product and from the technical documentation.","verdict":"1. Pass, if the mechanism for mutual authentication is implemented.\n2. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}}]},{"clause":"5.8","title":"Integrity protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (f).\n\n> EXAMPLE: Every PKI tree starts from the creation of the Certificate Authority. The administrator intervention is then to distribute the public part of the CA to all targets, which needs to trust the derived keys from this CA.","addressedBy":[],"otherRequirements":[],"mappingTable":{"INT_CONF-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"INT_CONF-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"INT_CONF-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"INT_ROTATE-4":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"INT_ROTATE-5":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"INT_ROTATE-6":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"INT_CONF-1","requirement":"The product shall interface only as defined in **CON_CHANNEL-5** implementing **CON_CHANNEL-6**.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set INT_CONF: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"All management actions and interactions between the product and the managed elements use only secure channels.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;","activities":"1. Study the technical documentation.\n2. Study the product and all available interfaces in operation.\n3. Monitor all network activity.","verdict":"1. Pass, if a secure channel is used in interfacing with the system.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"INT_CONF-2","requirement":"The product shall ensure that:\n 1. product configuration is protected against unauthorized modification and disclosure, and\n 2. only the intended managed element can obtain the relevant configuration, and\n 3. the element can verify the integrity of the configuration.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies products that distribute or make available configuration to managed elements.\n\nRequirement set INT_CONF: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The configuration data provided from the product to the managed element is protected against tampering and its integrity can be verified.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have a managed element connected to the system.\n3. Have a second managed element connected to the system.\n4. Have a third element that is not enrolled to the managed network.","activities":"1. Study the technical documentation.\n2. Initiate configuration transfer to the first managed element.\n3. Repeat transfer, and distort the configuration if it is possible by editing the content while keeping a valid schema.\n4. Attempt to transfer of the confiugration to the second element that is intented for the first one.\n5. Attempt to transfer of the configuration to the third element that is not enrolled.","verdict":"1. Pass, if the configuration transfer in step 2. succeeds\n2. and the configuration transfer attempt in steps 3., 4. and 5. fails.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"INT_CONF-3","requirement":"The configuration interfacing design shall enable the managed element to cryptographically verify the authenticity of the product.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set INT_CONF: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product supports authenticity requests received from its management elements.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have a managed element connected to the system.","activities":"1. Study the technical documentation.\n2. Study the connection towards the product from the managed element side.","verdict":"1. Pass, if the product supports the managed element’s cryptographic authenticity verification.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"INT_ROTATE-4","requirement":"The product shall support and implement an on-demand rotation of cryptographic keys.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set INT_ROTATE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"When employees and administrators roles change, the related keys are rotated.","preparation":"None","activities":"1. Study the technical documentation.\n2. Cross reference the instructions how and how often to do rotation of important keys to industry state-of-the art policies.","verdict":"1. Pass, if key rotation can be made on demand\n2. and the instructed rotation policy matches with the foreseeable use of the product\n3. and the keys can be initialised when the product is taken into use for a first time or after a reset to factory settings.\n4. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"INT_ROTATE-5","requirement":"The product shall support the initialisation of trust with the managed elements.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set INT_ROTATE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"New managed elements are initialised with shared secrets, trust anchors and with the product support.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have an untrusted network element to test with.","activities":"1. Study the technical documentation.\n2. Reset the managed element to factory defaults.\n3. Integrate the untrusted element as new managed element into the network.","verdict":"1. Pass, if a integrated managed element has the cryptographical keys and trust structures in use after the test actions.\n2. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"INT_ROTATE-6","requirement":"The product shall not trust expired secrets.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set INT_ROTATE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product operates only with valid keys.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;","activities":"1. Configure the product with an expired key.\n2. Reboot the necessary services.","verdict":"1. Pass, if an event is emitted to logs and the system operation is halted if the key is significant for the operation or the service.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.9","title":"Data minimisation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (g).\n\n> EXAMPLE: group-level accuracy may resemble\n> * application debug output\n> * application output labeled warning or critical\n> * privilege escalations in the application operation\n> * network configuration changes","addressedBy":[],"otherRequirements":[],"mappingTable":{"DM_RETENTION-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"DM_RETENTION-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"DM_RETENTION-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"DM_RETENTION-1","requirement":"The product shall define what is logged, and how long that record is kept by default, in group level accuracy.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set DM_RETENTION: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Ensure that the product user understands what data is being collected.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Cross-reference the product settings and output to the documentation.\n2. List the event types the product collects from managed elements out of present log files.","verdict":"1. Pass the presented categories matches the product operation\n2. and the listed retention times of the log records match with the expected use of the product.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"DM_RETENTION-2","requirement":"The product shall define which metrics are gathered, and how long those records are kept by describing, at minimum:\n 1. metric name\n 2. metric description\n 3. metric cadence, if relevant for the collected metric\n 4. default storage time","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set DM_RETENTION: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product collects only those metric data that are documented to the product user.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Cross-reference the product settings and output to the documentation.","verdict":"1. Pass, if the listed metric data types are available in the technical documentation\n2. and the collected metrics and the stored metric records matches the documentation.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"DM_RETENTION-3","requirement":"The product shall not collect data unrelated to the purpose of the product operation.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set DM_RETENTION: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product collects only those metric data types that are defined in the technical documentation.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Study the information provided by **DM_RETENTION-2** and **DM_RETENTION-3**","verdict":"1. Pass, if the ingested data follows the requirement definition.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.10","title":"Availability protection","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (h).\n\nFor **low** risk:\n\n> NOTE: **AP_HA-1** clarifies a common measurement misrepresentation. The requirement extends the **SU_UPDATE-2**. Updates are part of the product availability regardless of what layer is being updated.\n\nFor **medium** risk:\n\n* everything in low risk, and\n\nFor **high** risk:\n\n* everything in low risk, and\n* everything in medium risk, and","addressedBy":[],"otherRequirements":[],"mappingTable":{"AP_HA-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"AP_HA-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"AP_HA-3":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"AP_HA-4":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"AP_HA-5":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"AP_HA-6":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"AP_HA-7":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"}},"requirements":[{"id":"AP_HA-1","requirement":"Operating system, if part of the product, or product updates and changes shall not be considered as exceptions in the product general availability definition.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AP_HA, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Events by changes of the product itself that impact the product availability do not render the product behaviour unpredictable. The product keeps the availability time definitions.","preparation":"1. Study the technical documentation;","activities":"1. Study the metrcis definition and define what would happen if a operating system update outside of the product context as defined in **SU_UPDATE-2**","verdict":"1. Pass, if the product availability definition does not list exceptional events that are not counted towards availability.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-2","requirement":"The product shall emit security events about detected issues that affect the availability of the product and its provided services.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"applicabilityText":"Requirement set AP_HA, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"A product and product-services outage, or a performance decrease trigger a security event.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation","activities":"1. Study the technical documentation;\n2. Disconnect or make unavailable a service, a compute node, a rack, or a datacenter based on the tolerable disturbances provided in the technical documentation.","verdict":"1. Pass, if an event is emitted as a result of the test activity.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-3","requirement":"The product shall tolerate loss of external resources within the limits of the defined availability.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set AP_HA, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Even during the specified tolerable loss of essential external resources, the product remains operational.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the availability definition from the documentation.\n2. Disconnect or make unavailable a service, a compute node, a rack, or a datacenter based on the tolerable definitions provided in the technical documentation.\n3. Wait for stability.\n4. Reconnect or make available the previously removed resource.\n5. Wait for stability.","verdict":"1. Pass if recovery expectations are clearly defined,\n2. and the system returns to stability after removal of the the maximum capacity mentioned in the toleration description,\n3. and the deleted or removed resources returns operation after they are reintroduced to the system,\n4. and the defined high availability is held.\n5. Fail otherwise.\n\n> NOTE: The selection of the resource to be removed should meet the principal of the most needed or having the highest priority resource for the expected product operations.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-4","requirement":"The product shall minimise the impact to other systems when anomalies occur.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set AP_HA, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"In case of product anomalies the product limits its impact on the managed elements or other dependent systems operation.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Terminate arbitrarily one or more processes operated on the product;\n2. Check whether such disruption impacts the managed element operation or other dependent systems operation.","verdict":"1. Pass, if the affected product disruptions do not impact the managed element or other dependent systems operation\n2. and the product resumes services after the disruptions have been removed.\n3. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-5","requirement":"The product shall implement coordinated brute‑force and overload protection mechanisms that not only detect excessive authentication attempts or inbound traffic surges, but also enforce active mitigation actions, including at minimum\n 1. temporary IP blocking, and\n 2. message buffering, and\n 3. QoS parameterisation.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set AP_HA, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product defences itself against brute-force and overload attacks, and enforces countermeasures.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Ensure brute force and overload protections available are enabled and configured as per manufacturers instructions.","activities":"1. From a test host, generate repeated login attempts without valid credentials exceeding the expected threshold.\n2. Observe detection and expected reaction to the generated traffic.","verdict":"1. Pass if the expected reaction is made by the system.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-6","requirement":"The product shall implement recovery or failover mechanisms.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set AP_HA, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product recovers in total or in parts from crashes or achieves a secure failover state in case the failure persists.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Identify queues/handlers that can buffer incoming work (Eg: task queues, batch operations);\n3. Identify the failover mechanisms in place.","activities":"1. Feed the system with large volume of batch jobs or messages;\n2. Execute concurrent operations in accordance;\n3. Confirm the operations are batched and system is still serving requests and is not unresponsive;\n4. Repeat the task flooding and kill a process, node or a datacenter that within the toleration of the availability and time the disturbance to the moment processing is ongoing;\n5. Verify the successful completion of the test jobs.","verdict":"1. Pass if buffering and task queuing is performed within the queue depth or metrics as per the manufactured defined limits\n2. and the system load reduces as the tasks complete\n3. and the failover mechanisms function without intervention.\n4. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}},{"id":"AP_HA-7","requirement":"The product shall implement DDoS mitigations including at minimum:\n 1. detection and logging of volumetric or protocol abuse affecting product availability;\n 2. active mitigation actions that preserve or restore essential management functions within a configurable timeframe;\n 3. rate limiting, traffic shaping, connection throttling, or temporary blocking of abusive sources;\n 4. controlled degradation, traffic redirection, or temporary suspension of non-essential services or interfaces for a configurable time;\n 5. coordination with external DDoS defence or scrubbing systems where documented as part of the operational environment (see CYB_OPS-1).","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"This requirement applies to products which can be exposed to DDoS.\n\nRequirement set AP_HA, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product protects itself from denial of service attacks with present countermeasures.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Ensure DDoS protections available are enabled and configured as per manufacturers instructions.","activities":"1. Flood the product with data packages from a simulator;\n2. Check that the defined DDoS protection mechanisms get triggered;\n3. Observe the mechanism operation and the resulting effects;\n4. Confirm the system is still serving requests and is not unresponsive.","verdict":"1. Pass, if all relevant features are available as defined and mitigates DDoS attack is mitigated.\n1. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.","guidance":""}}]},{"clause":"5.11","title":"Non-interference","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (i).\n\nFor **low** risk:\n\nFor **medium** risk:\n\n* everything in low risk, and\n\n> EXAMPLE: A reasonably limited known source would be RFC 1918 [8] private subnet.\n\n> NOTE: The requirement **IM_SEGMENT-2** is designed to be combined with **EMM_ROUTE-2** to reach the required level of protection.\n\nFor **high** risk:\n\n* everything in low risk, and\n* everything in medium risk, and\n\n> NOTE: In default configuration applies to all interfaces regardless of the connectivity.\n\n> NOTE: The requirement **CYB_OPS-2** classifies management traffic to be Application level traffic making the low level OT designs incompatible with this document.","addressedBy":[],"otherRequirements":[],"mappingTable":{"IM_SEGMENT-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"IM_SEGMENT-2":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"IM_SEGMENT-3":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"}},"requirements":[{"id":"IM_SEGMENT-1","requirement":"The product shall support network segmentation for management traffic where applicable.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"required"},"applicabilityText":"Requirement set IM_SEGMENT, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: low; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the interface against unclassified traffic.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Study the implementation of the product and determine if the management traffic would be possible to segregate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of the network served with the product.","verdict":"1. Pass the product **instructs** the product user how to deploy and communicate management traffic via a separated network segment.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"IM_SEGMENT-2","requirement":"Available management APIs shall accept traffic only from reasonably limited known sources.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set IM_SEGMENT, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: low; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the interface against unclassified traffic.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Study the implementation of the product and determine if the management traffic would be possible to segregate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of the network served with the product.","verdict":"1. Pass if the product **supports** utilising dedicated physical port for the management traffic or the product supports dedicated virtual subnet to be connected to the serving workload that is segregated from SRU traffic\n1. and the product instructs the product user how to deploy and use the provided product features.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"IM_SEGMENT-3","requirement":"Available interfaces shall accept traffic only from a dedicated virtually or physically connected subnet.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"not-required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"not-required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set IM_SEGMENT, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: low; UC-9-RESEARCH: none; UC-10-AIRGAP: none; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the interface on unclassified traffic.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to deploy the system.","activities":"1. Study the implementation of the product and determine if the management traffic would be possible to segregate to its own physical or virtual interface or subnet where a layer of authorisation could be used to segregate the traffic towards the product from other uses of the network served with the product.\n2. Study the implementation of the product and determine if the management API is designed to reject unclassified network traffic.\n3. Simulate unclassified network traffic on the management API.","verdict":"1. Pass, if the product **requires** utilising dedicated physical port for the management traffic or the product supports dedicated virtual subnet to be connected to the serving workload that is segregated from other traffic\n2. and the product reject network traffic that is not conformant to the connected networks and subnetworks\n3. and the simulated unclassified network traffic is rejected.\n4. and the product instructs the product user how to deploy and connect to the networks and subnetworks in classified ways.\n5. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.12","title":"Attack surface minimisation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (j).","addressedBy":[],"otherRequirements":[],"mappingTable":{"MAS_TECH-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MAS_TECH-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"MAS_TECH-1","requirement":"The product shall:\n 1. document all communication interfaces, and\n 2. refrain from exposing any interfaces or initiating connections other than those documented, and\n 3. disable by default interfaces not required for the intended use.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MAS_TECH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product user knows entirely all external product interfaces.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation;\n2. Study the listed documented communication endpoints;\n3. List all the interfaces the product is listening to or writing to;\n4. Cross-reference the open interfaces to the documentation.","verdict":"1. Pass, if all interfaces used for communication are documented;\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MAS_TECH-2","requirement":"The product shall not connect to undocumented RDPS services.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MAS_TECH: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"How the product communicates with RDPS is documented and made known to the product user.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the technical documentation.\n2. Study the listed dependencies to RDPS systems.\n3. Capture all network traffic metadata that occurs by the product RDPS communication.\n4. Trigger all possible actions that might result in a communication with RDPS services, like update, licensing verifications, etc.\n5. Identify all systems with the help of the technical documentation.","verdict":"1. Pass, if the product does not initiate a connection with an undefined target.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.13","title":"Exploit mitigation","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (k).\n\nFor **low** risk:\n\nFor **medium** risk:\n\n* everything in low risk, and\n\nFor **high** risk:\n\n* everything in low risk, and\n* everything in medium risk, and","addressedBy":[],"otherRequirements":[],"mappingTable":{"EMM_ROUTE-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"EMM_ROUTE-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"EMM_ROUTE-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"}},"requirements":[{"id":"EMM_ROUTE-1","requirement":"Where management connections to managed elements are not wholly contained within a dedicated trusted management segment documented per **IM_SEGMENT** and **CYB_OPS-1**, the product or documented operational environment shall enforce controls that limit management traffic by managed element or server identity and destination address, appropriate to the intended and reasonably foreseeable use.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set EMM_ROUTE, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: high; UC-2-ENTER-S: high; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the network from compromised elements.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation","activities":"1. Investigate the implementation.","verdict":"1. Pass, if documented controls demonstrably limit management traffic by managed element identity and destination for the deployment model, or if non-applicability is justified per **IM_SEGMENT** and CYB_OPS-1.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"EMM_ROUTE-2","requirement":"The product shall only permit traffic that is validated and explicitly authorized to transit the management connection.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set EMM_ROUTE, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: high; UC-2-ENTER-S: high; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the network from compromised elements.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation","activities":"1. Investigate the implementation and check whether communication is established and occurs only between the product and authorised manged elements that are permitted to address the management interface.","verdict":"1. Pass, if only management and control traffic is allowed in the link between the product and the managed element.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"EMM_ROUTE-3","requirement":"The product shall emit an auditable event from out-of-place traffic.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set EMM_ROUTE, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: high; UC-2-ENTER-S: high; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: medium.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Enable product user investigations in case of occurring out-of-place-traffic.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation","activities":"1. Investigate the implementation.\n2. Send maliciously crafted packets toward the interface.\n3. Perform actions that are not classified as management traffic to the management API.","verdict":"1. Pass, if an event is emitted summarising the detected rogue traffic.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.14","title":"Monitoring","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (l).\n\nFor **low** risk:\n\n> NOTE: **MON_LOG-7** Writing a log record in case of an error during the booting process might not be possible in all cases, as the product is not completely functional when the booting process has not successfully completed. The event recording function is made available during the booting process.\n\nFor **medium** risk:\n\n* everything in low risk, and\n\nFor **high** risk:\n\n* everything in low risk, and\n* everything in medium risk, and\n\n> NOTE: **MON_LOG-13** describes privilege escalations that are done in computation. A common tactic to infiltrate a system is to trick it to escalate attacker access rights.\n\n> NOTE: **MON_METRICS-16** leaves open how the information is conveyed to the product user. It could be a dedicated portal within the product or machine readable output having the same information.","addressedBy":[],"otherRequirements":[],"mappingTable":{"MON_LOG-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-3":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-4":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-5":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-6":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-7":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_LOG-8":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_LOG-9":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_LOG-10":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_LOG-11":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_LOG-12":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_LOG-13":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"MON_METRICS-14":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_METRICS-15":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_METRICS-16":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"MON_METRICS-17":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"MON_LOG-1","requirement":"The product shall protect log data of events from unauthorized access.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The logs are protected from disclosure and alteration.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Access the collected logs the expected way.\n2. Access the collected logs the expected way without valid authorisation.\n3. Access the collected logs un-expected way without valid authorisation.","verdict":"1. Pass if access is denied\n2. and if the event is detected and logged.\n3. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-2","requirement":"The product shall protect log data of events from modification including their deletion, execpt if the modification relates to an execution of planned rotation policy in the product.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The logs are protected from alteration including their deletion.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Access the collected logs the expected way;\n2. Access the collected logs the expected way with valid authorisation, make an alteration to one and try to delete another log entry.","verdict":"1. Pass, if the product detects the alteration of logs and prevents the deletion.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-3","requirement":"The product shall protect the confidentiality of events within log data.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Protect the logs leaking information.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Study the product and the implementation.","verdict":"1. Pass, if the logging system protects the reading access to the log data in transit and at rest.\n2. Fail if the data stored in local disk is accessible by all locally authenticated users without restrictions.\n3. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-4","requirement":"The product shall include, at minimum, the following fields in a machine-readable format in its log data:\n 1. event timestamp,\n 2. actor identity,\n 3. action type,\n 4. affected non-sensitive scope, and\n 5. object identifiers.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Each log entry contains a minimum set of information enabling for an analysis of the logged event.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation how to interact with the system;","activities":"1. Study the log output.","verdict":"1. Pass if listed information is available in the log event systemically in the same machine readable manner.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-5","requirement":"The product shall log all received relevant events from its managed elements in a machine readable format including, at minimum:\n 1. incidents\n 2. alarms\n 3. time shift alarms.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"All defined event notifications received from the managed elements are recorded in a machine-readable format and enable for machine-based analysis.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have the managed element initialised and available with the required credentials;\n3. Study the technical documentation on how to interact with the system.","activities":"1. Emit listed events from the managed element;\n2. Study the log output.","verdict":"1. Pass if listed information is available in the log event systemically in a machine readable manner.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-6","requirement":"The product shall generate auditable events including, at minimum:\n 1. successful and failed authentication events\n 2. session establishment attempts with source details\n 3. session termination events with a reason\n 4. session validation checks like number of concurrent sessions\n 5. privilege and role changes\n 6. configuration changes\n 7. element enrollment and unenrollment\n 8. trust-anchor changes\n 9. policy changes\n 10. credential changes\n 11. events described by [5.5 Security updates](#55-security-updates)\n 12. installation successes and failures in the managed elements, if that information can be extracted from the targets\n 13. installation successes and failures in the product itself.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to the subset of products that support the corresponding function for each item.\n\nRequirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product’s logging records enable for the analysis of the product behaviour.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have the managed element initialised and available with the required credentials;\n3. Study the technical documentation on how to interact with the system.","activities":"1. Interact with the system to create all described events;\n2. Study the log output.","verdict":"1. Pass if all required information is available in the log systemically in a machine readable manner.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-7","requirement":"The product shall log boot or initialisation events including at minimum:\n 1. timestamped boot stage progression,\n 2. software component verification and initialisation actions, and\n 3. recovery mode activations if in use.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"This requirement applies to the subset of products that support the corresponding function for each item.\n\nRequirement set MON_LOG, low-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The log records allow to analyse whether the product has achieved the operational status or whether an error occurred in dependency of the achieved booting stage.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have the managed element initialised and available with the required credentials;\n3. Study the technical documentation on how to interact with the system.","activities":"1. Interact with the system to create described event;\n2. Study the log output.","verdict":"1. Pass if required information is available in the log systemically in a machine readable manner.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-8","requirement":"The product shall actively schedule backups for log information.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Even attackers who managed to gain access to the logging records cannot alter or eliminate the history as the logging has a scheduled external backup.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to interact with the system.","activities":"1. Check whether the product provides a product user-set scheduled backup of the log records.\n2. Verify that the scheduling of the backups is indeed applied.","verdict":"1. Pass if backup is scheduled and working.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-9","requirement":"The product shall maintain tamper-evident audit logs.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, medium-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Even attackers who managed to gain access to the logging records cannot alter or eliminate the history.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to interact with the system.","activities":"1. Identify how the logging mechanism works;\n2. Change the logging storage outside of the product control while maintaining the schema.","verdict":"1. Pass if modification was noticed.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-10","requirement":"The product shall support forwarding of relevant administrative events to an external logging or SIEM system.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Administrative events can be audited within the logs or at a SIEM system.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to interact with the system.\n3. Have an external logging SIEM system available and configured to receive events.","activities":"1. Make an action that is expected to generate an auditable event;\n2. Study the event notification and cross reference the content to the technical documentation;\n3. Check whether the event is externally made available in the logging or SIEM system.","verdict":"1. Pass, if the event notification is product-external available.\n2. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-11","requirement":"The product shall produce logs, SIEM event data transfer format, field attributes and event descriptions in a machine readable format.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Logging records, product-internal and on external systems, are machine readable and can be analysed in automated ways.","preparation":"None","activities":"None","verdict":"1. Pass, if the logging records are available product-external and are in a machine-readable format.\n2. Fail, if evidence cannot be exported or loses critical context.\n3. Fail otherwise.","evidence":"1. Pointers to the documentation.\n2. Screenshot of machine-readable logging records.\n3. References to the belonging documentation of record contents and formats.","guidance":""}},{"id":"MON_LOG-12","requirement":"The product shall export logs as data artifacts that preserve essential fields, at minimum:\n 1. timestamp when the event occurred\n 2. actor\n 3. action type\n 4. affected scope\n 5. result.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The exported logging records provide a minimum set of information about the basic data of the event as defined to enable the product user for event analysis.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to interact with the system.","activities":"1. Make an action that is expected to generate an auditable event.\n2. Study the log output.","verdict":"1. Pass if all required information is available in in each logging record.\n2. Fail otherwise.","evidence":"* Screenshot or console ouput of the logging records with identification of the minimum information parameters;\n* References to the belonging documentation of record contents and formats;\n* Metrics output relevant for the activities, if available;\n* Test reports showing the steps performed and results obtained;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"MON_LOG-13","requirement":"The product shall record sufficient provenance information to attribute a change to an actor and context information related to, at minimum:\n 1. authoritative subject\n 2. automated workflow if relevant for the event context\n 3. policy or rule identifier\n 4. and triggering event reference.","applicability":{"UC-1-HOME":"not-required","UC-2-ENTER-S":"not-required","UC-2-ENTER-M":"not-required","UC-2-ENTER-L":"not-required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"not-required","UC-7-ICT":"not-required","UC-8-FLEET":"required","UC-9-RESEARCH":"not-required","UC-10-AIRGAP":"required","UC-11-WATER":"not-required"},"applicabilityText":"Requirement set MON_LOG, high-risk tier (tiers are cumulative per clause 5.1). Table 5.1 sets the required tier per use case: UC-1-HOME: low; UC-2-ENTER-S: medium; UC-2-ENTER-M: medium; UC-2-ENTER-L: medium; UC-3-TELCO: high; UC-4-SDN: high; UC-5-HYBRID: high; UC-6-IOT: medium; UC-7-ICT: medium; UC-8-FLEET: high; UC-9-RESEARCH: none; UC-10-AIRGAP: high; UC-11-WATER: low.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The recorded event data enable to analyze the actor and context of the event.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Study the technical documentation on how to interact with the system.","activities":"1. Make an action that is expected to generate an auditable event;\n2. Study the log output.","verdict":"1. Pass, if the action applied can be attributed to actor and context with retrievable references.\n2. Fail if changes cannot be deterministically attributed.\n3. Fail otherwise.","evidence":"1. References to the belonging documentation of record contents and formats.\n2. Screenshot or console output of the logging records with identification of the minimum information parameters.","guidance":""}},{"id":"MON_METRICS-14","requirement":"The product shall prevent alteration of collected and stored metrics data.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_METRICS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The ingestion pipeline design protects the metric data integrity.","preparation":"None","activities":"1. Study the technical documentation.","verdict":"1. Pass if no unauthorised process before ingestion of collected metrics data can alter the metrics before storage\n2. and if the storage can not be altered outside of desired storage handling.\n3. Fail otherwise.","evidence":"1. References to documentation sections.","guidance":""}},{"id":"MON_METRICS-15","requirement":"The product shall dispatch an event noting the import of previously recorded metric data if that data will overwrite existing data.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_METRICS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Stored data wiping or overwriting can always be recognized.","preparation":"1. Have the product initialised and available with the default configuration;\n2. Create required authentication credentials for the test;\n3. Prepare an import data set that represents normal operational metric data from a managed element;\n4. Create a copy of the import data set and modify the data to change also related integrity protection values.","activities":"1. Begin a time series data collection;\n2. Restart the collection of timeseries data with the modified data set.","verdict":"Pass if systems detects the modified data set.","evidence":"1. Collect output showing the whether the current metrics data is being handled by the normal flow as expected;\n2. Collect output showing how the modified data set was accepted or discarded.","guidance":""}},{"id":"MON_METRICS-16","requirement":"The product shall record metrics name, purpose, and value interpretation shall in a manner accessible to the product user.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_METRICS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The user has explanations about the meaning of each metric and is enabled to interpret those. Furthermore, the explanations clarify the relevance of collected metric data.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.","activities":"1. Study the monitoring data GUI;\n1. Study the provided documentation;\n1. Investigate the metrics storage.","verdict":"1. Pass if there are no unknown metrics displayed or collected\n2. and if there are commonly well-known metrics displayed or collected, like CPU usage, which can remain without explanation\n3. and if a metric is recognised and a pointer to the documentation is provided (managed element manufacturer’s reference documentation e.g.).\n4. Fail otherwise.","evidence":"1. Output samples showing how the information is conveyed for the user.\n\n> NOTE: Whether a modified data set gets accepted or discarded might not be the product's but an administrator decision.","guidance":""}},{"id":"MON_METRICS-17","requirement":"The product shall collect, track, and store metrics on, at minimum:\n 1. availability and status changes, like process and service crashes and restarts\n 2. incidents, warning and notification events reported by the target\n 3. relevant operative information like CPU, memory, disk utilisation\n 4. relevant networking metrics like throughput and protocol errors\n 5. relevant databases and storage health metrics like queries per second, latency and throughput\n 6. GUI and API latencies, where available\n\n from the following targets:\n\n 7. managed elements, where such metrics are available or can be reasonably synthetized\n 8. provided services\n 9. the system itself.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set MON_METRICS: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"Monitoring metrics fulfills multiple objectives, including:\n\n* Support users or administrators ability to detect compromised, misconfigured, or harmful connected elements through unusual, excessive, or risky patterns of use;\n* To detect availability issues;\n* Out of the normal behaviour, metrics indicate failures or compromise of both the managed elements and the product;\n* The error metrics enable for tracing and serve as entry point for the analysis and detection of abnormal behavior in the managed element and in the system;\n* Response latencies on the product queries or protocol errors on incoming data from managed elements enable it to detect defective or compromised managed elements.\n* The product provides a recording of the listed minimum set of data types.","preparation":"1. Have the product initialised and available with the default configuration and required credentials;\n2. Have at least one managed element as part of the system the product operates;\n3. Have the managed element initialised and available with the required credentials;\n4. Study the deployment instructions about sizing of the operative environment;\n5. Study the technical documentation how to interact with the collected metrics data;","activities":"1. Study the provided technical documentation how to interpret the monitoring data;\n2. Simulate abnormal behaviour by intentionally cutting the connection with a managed element and observe the monitoring data;\n3. Restart the managed element;\n4. Purposefully crash a process or restart a connected element;\n5. Purposefully crash a product process;\n6. Generate large amount of traffic in a random location;\n7. Send a correct API request from the product towards each managed element API endpoint;\n8. Send a correct API request from the managed element towards the product API endpoint;\n9. Send an incorrect API request towards each system API endpoint;\n10. Send a momentary spike of requests that exceeds the reasonable and expected load of incoming requests.\n\nOutcomes:\n\n1. Study the product behaviour from the collected metrics in terms of:\n 1. process recovery\n 2. how the listed test activities are displayed in the collected metrics.","verdict":"1. Pass if basic administrative metrics are tracked and displayed\n2. and if the product process or the product recovers to normal operation\n3. and if the connection loss to the managed element is recognized\n4. and if by observing the metrics a baseline of the system operation can be established\n5. and if anomalies like load spikes after a restart can be observed\n6. and if the product detects and displays or reports the test event on the managed element\n7. and if the product monitoring data shows the expected operation statuses where applicable for both, the product and for the managed elements:\n * success rate\n * operation failure rate\n * query execution time\n * response size\n8. and if the monitoring data the expected operations and their statuses per connected element and relevant system processes\n9. and if the monitoring data and notifies the disconnection from the provided service\n10. and if the disconnected service can be identified in the metrics\n11. and if corresponding metrics matches the generated traffic\n12. and if all API endpoints responds as expected\n13. and if the response latency is recorded in defined accuracy, where reasonably available\n14. and if system tracks the number of successful requests, where reasonably available\n15. and if the incorrect API requests are identified and accounted\n16. and if the spike of high volume requests is handled gracefully.\n17. Fail otherwise.","evidence":"* Metrics output relevant for the activities, if available;\n* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]},{"clause":"5.15","title":"Factory reset and data portability","overview":"This clause addresses the requirements in the CRA [i.1\\] Annex 1 Part 1 (2) (m).\n\n> NOTE: Due to complexity, and industry wide use of various protocols and best practices, the support for data transfer is not required.","addressedBy":[],"otherRequirements":[],"mappingTable":{"DRT_DELETE-1":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"DRT_DELETE-2":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"}},"requirements":[{"id":"DRT_DELETE-1","requirement":"The product shall:\n 1. provide a function to remove all data and settings, or\n 2. support full re-installation to restore to its secure-by-default state.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set DRT_DELETE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"The product user can remove all of his data from the product.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation","activities":"1. Change the product state in a way that generates storable information to all data storage solutions.\n2. Perform deletion as instructed.\n3. Investigate the data storage used in the product.","verdict":"1. Pass, if generated data was removed from all storage solutions.\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}},{"id":"DRT_DELETE-2","requirement":"If import and export of data is available, the related data transfer shall implement **INT_CONF-1**.","applicability":{"UC-1-HOME":"required","UC-2-ENTER-S":"required","UC-2-ENTER-M":"required","UC-2-ENTER-L":"required","UC-3-TELCO":"required","UC-4-SDN":"required","UC-5-HYBRID":"required","UC-6-IOT":"required","UC-7-ICT":"required","UC-8-FLEET":"required","UC-9-RESEARCH":"required","UC-10-AIRGAP":"required","UC-11-WATER":"required"},"applicabilityText":"Requirement set DRT_DELETE: Table 5.1 requires the full set (\"all\") for every use case.","applicabilitySource":"table-5.1-requirement-sets","assessment":{"objective":"If applicable, the product user can import or export data with a secure channel.","preparation":"1. Have the product initialised and available with the default configuration and required credentials.\n2. Study the technical documentation\n3. Change the product state in a way that generates stored data and generate outside the product a data set","activities":"1. Export the previously in-product generated data and verify that a secure protocol as out of Annex K is deployed\n2. Import the externally present data set and verify that a secure protocol as out of Annex K is deployed","verdict":"1. Pass, if for import and export a protocol as of Annex K is deployed\n2. Fail otherwise.","evidence":"* Relevant vendor or design documentation describing the applied measures;\n* Test reports showing the steps performed and results obtained;\n* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;\n* Logs, configuration files, or audit traces demonstrating the implementation of the requirement;","guidance":""}}]}],"annexK":{"general":"The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1.\n\nFor ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in clause K.3.2 or fulfils the criteria specified in clause K.1.1 item 2.b. For interoperability-based cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is listed in clause K.4.2. The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.","requirements":[{"id":"REQ-K-CRYPTO-CONF","family":"Annex K — Cryptography","requirement":"[Clause K.1.1] The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:\n\n1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \\[i.8\\].\n2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue \\[i.8\\] and meets at least one of the following conditions:\n 1. the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);\n 2. where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:\n 1. 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 \\[i.8\\];\n 2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation 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 recognised 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;\n 3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;\n 4. the cryptographic properties of the cryptographic mechanism are known;\n 5. no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;\n 6. the cryptographic mechanism is required for a specific set of product functions;\n 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).\n\n> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.\n\n> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.\n\n> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document. The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.\n\n> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context. An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.\n\n> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.\n\n> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.","applicability":{},"applicabilityText":"Applies to cryptographic mechanisms used in the product's default configuration (clause K.1.1); clause 5 ties Annex K in through SBD_TECH-1, AAC_AUTH-8 and CON_CHANNEL-4.","assessment":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 1) and used in the product’s default configuration are listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1\\].","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 1), including the related product function, relevant parameters where applicable, and the relevant ACM entry.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry;\n- b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable;\n- c) where the ACM entry includes lifecycle information, such as expiry date, deprecation date, migration condition or usage limitation, this information is reflected in the documentation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 1);\n- c) references to the relevant ACM entries;\n- d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable;\n- e) relevant lifecycle information from the ACM catalogue, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 1).\n- The verdict FAIL shall be assigned otherwise.","guidance":"The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1.\n\nFor ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in clause K.3.2 or fulfils the criteria specified in clause K.1.1 item 2.b. For interoperability-based cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is listed in clause K.4.2. The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document."}},{"id":"REQ-K-ACM-EXTENDED","family":"Annex K — Cryptography","requirement":"[Clause K.3.1] Where the product’s default configuration uses ACM-extended cryptographic mechanisms, these mechanisms shall comply with the ACM-extended criterion in clause K.1.1 item 2.","applicability":{},"applicabilityText":"Per clause K.3.1: applies where the product's default configuration uses ACM-extended cryptographic mechanisms. Assessed per clause K.1.2.2 (clause K.3.3).","assessment":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 2) and used in the product’s default configuration are either listed as ACM-extended cryptographic mechanisms in clause K.3.2 or fulfil the criteria specified in clause K.1.1 item 2.b, and are used for the claimed product function(s).","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 2), including the related product function, use case where applicable, relevant parameters where applicable, and at least one of the following:\n - a) the relevant entry in clause K.3.2; or\n - b) evidence that the cryptographic mechanism fulfils all applicable criteria in clause K.1.1 item 2.b.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 2) is either listed in clause K.3.2 as an ACM-extended cryptographic mechanism or supported by evidence demonstrating fulfilment of the applicable criteria in clause K.1.1 item 2.b;\n- b) the cryptographic mechanism used by the product corresponds to the mechanism listed in clause K.3.2 or described in the evidence provided under clause K.1.1 item 2.b;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.3.2 or justified under clause K.1.1 item 2.b;\n- d) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.3.2 or justified under clause K.1.1 item 2.b, where applicable;\n- e) where clause K.3.2 or the justification under clause K.1.1 item 2.b defines conditions or limitations for the use of the cryptographic mechanism, these conditions or limitations are reflected in the product’s default configuration;\n- f) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 2);\n- c) reference to the relevant entry in clause K.3.2, where the mechanism is listed in clause K.3.2;\n- d) evidence that the cryptographic mechanism fulfils the criteria in clause K.1.1 item 2.b, where compliance with clause K.1.1 item 2 is claimed on the basis of those criteria;\n- e) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.3.2 or in the justification under clause K.1.1 item 2.b, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 2).\n- The verdict FAIL shall be assigned otherwise.","guidance":""}},{"id":"REQ-K-INTEROP","family":"Annex K — Cryptography","requirement":"[Clause K.4.1] Where the product’s default configuration uses interoperability-based cryptographic mechanisms, these mechanisms shall be selected from the interoperability-based cryptographic mechanisms listed in clause K.4.2 for the specified product functions and external specifications or external requirements and shall be used in accordance with the conditions or limitations specified in clause K.4.2.","applicability":{},"applicabilityText":"Per clause K.4.1: applies where the product's default configuration uses interoperability-based cryptographic mechanisms. Assessed per clause K.1.2.3 (clause K.4.3).","assessment":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 3) and used in the product’s default configuration are listed as interoperability-based cryptographic mechanisms in clause K.4.2 and are used in accordance with the characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in clause K.4.2.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 3), including the related product function, use case where applicable, relevant parameters where applicable, the external specification or external requirement requiring its use, and the relevant entry in clause K.4.2.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 3) is listed in clause K.4.2 as an interoperability-based cryptographic mechanism;\n- b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in clause K.4.2;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.4.2;\n- d) the external specification or external requirement requiring the use of the cryptographic mechanism corresponds to the external specification or external requirement specified in clause K.4.2;\n- e) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.4.2, where applicable;\n- f) the conditions or limitations specified in clause K.4.2 for the use of the cryptographic mechanism are reflected in the product’s default configuration;\n- g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 3);\n- c) reference to the relevant entry in clause K.4.2;\n- d) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- e) identification of the external specification or external requirement requiring use of the cryptographic mechanism;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.4.2.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 3).\n- The verdict FAIL shall be assigned otherwise.\n\n> NOTE 1: The assessment of the external specification or external requirement itself is outside the scope of this assessment case. The assessment verifies that the external specification or external requirement is identified in clause K.4.2 and that the cryptographic mechanism is used by the product for the related product function.\n\n> NOTE 2: Documentation review is a minimum assessment activity under the present annex. Functional and/or resistance testing activities can be added by vertical standards where relevant for the product category, product function or cryptographic mechanism.","guidance":""}},{"id":"REQ-K-CRYPTO-AGILITY","family":"Annex K — Cryptography","requirement":"[Clause K.2.1] Where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product shall provide means for addressing the affected cryptographic mechanism by one or more of the following:\n\n- a) updating the cryptographic mechanism;\n- b) using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation;\n- c) disabling the use of the affected cryptographic mechanism; or\n- d) limiting the use of the affected product functions accordingly.\n\n> EXAMPLE: Where a security mechanism uses a hybrid cryptographic construction, for example a hybrid key-encapsulation mechanism combining a classical and a post-quantum primitive, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization can be used as part of a planned migration strategy where permitted by the ACM catalogue or by the present document. However, hybridization does not, by itself, extend the recommended usage lifetime of a constituent primitive that has been deprecated.\n\n> NOTE 1: Where a hybrid cryptographic construction includes multiple cryptographic primitives, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization is not assumed to mitigate the deprecation of a constituent primitive unless the ACM catalogue or the present document classifies the hybrid construction as suitable for the corresponding product function.\n\n> NOTE 2: Crypto agility supports maintaining appropriate cryptographic protection within the intended lifetime of the product, in addition to the capability of updating cryptographic mechanisms on the product in accordance with secure update and secure communication mechanisms.\n\n> NOTE 3: Deprecation information from sources other than the ACM catalogue or the present document can be considered as input to vulnerability management or security risk assessment but does not by itself trigger the requirement in clause K.2.1.\n\n> NOTE 4: Where the product provides cryptographic capabilities for use by other products, components or layers, the mechanism required by clause K.2.1 can consist of update, configuration, disabling, deprecation or limitation capabilities usable by the integrating product, system operator or user, where applicable.\n\n> NOTE 5: The applicability condition of this requirement can express exceptions based on product characteristics, e.g. cryptographic implementation based on immutable hardware co-processor(s) or hardware-based root of trust, or long-lived silicon used in a long-lived non-updateable environment.","applicability":{},"applicabilityText":"Per clause K.2.1: applies where a cryptographic mechanism used by the default configuration has an ACM deprecation/expiry/migration condition or usage limitation within the product's intended lifetime.","assessment":{"objective":"The purpose of this assessment case is to verify whether, where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product provides means to address the affected cryptographic mechanism in accordance with clause K.2.1.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall identify:\n - a) the intended lifetime of the product;\n - b) the cryptographic mechanisms used in the product’s default configuration;\n - c) the related product function(s) for each cryptographic mechanism;\n - d) the lifecycle information applicable to each cryptographic mechanism, where specified by the ACM catalogue or the present document, including any deprecation date, expiry date, migration condition or usage limitation.","activities":"The assessment shall include verification that:\n\n- a) for each cryptographic mechanism used in the product’s default configuration, the lifecycle information specified by the ACM catalogue or the present document has been identified, where such information is specified;\n- b) where the ACM catalogue or the present document specifies a deprecation date, expiry date, migration condition or usage limitation for a cryptographic mechanism, this information is reflected in the documentation;\n- c) where a deprecation date, expiry date, migration condition or usage limitation falls within the intended lifetime of the product, the product provides an applicable mechanism for updating the cryptographic mechanism, using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation, disabling the use of the affected cryptographic mechanism, or limiting the use of the affected product functions accordingly;\n- d) where another cryptographic mechanism is used, that cryptographic mechanism complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) documentation of the intended lifetime of the product;\n- b) list of cryptographic mechanisms used in the product’s default configuration;\n- c) identification of the related product function(s) for each cryptographic mechanism;\n- d) references to the ACM catalogue entry or to the provision of the present document used to determine lifecycle information, where applicable;\n- e) identification of any deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product;\n- f) description of the means provided by the product, such as update of the cryptographic mechanism, use of another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant lifecycle constraint, disabling the use of the affected cryptographic mechanism, or limitation of the use of the affected product functions.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.2.1.\n- The verdict FAIL shall be assigned otherwise.","guidance":""}}]},"rdps":{"applicability":"Where the product does not rely on remote data processing solutions for the provision or support of any product function, this annex is not applicable.\n\nThe requirements in the present clause address the protection of the security properties identified for the assets in [clause R.3.2](#r.3.2-assets).\n\nWhere a security property is identified as relevant for a given asset in the asset tables of [clause R.3.2](#r.3.2-assets), the corresponding requirement family or families in the present clause shall be considered for applicability to that asset.\n\nFor **DA-RDPS-001**, the primary requirement families considered for applicability are:\n\n- a) data authenticity of interactions;\n- b) integrity of interactions; and\n- c) confidentiality of exchanged data.\n\nFor **DA-RDPS-002**, the primary requirement family considered for applicability is availability.","families":[{"clause":"R.4.2.1","title":"Data authenticity of interactions received from the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-AUTH"]},{"clause":"R.4.2.2","title":"Integrity of interactions received from the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-INTEG"]},{"clause":"R.4.2.3","title":"Confidentiality of data exchanged with the RDPS side","side":"local","requirementIds":["REQ-RDPS-L-CONF"]},{"clause":"R.4.2.4","title":"Availability","side":"local","requirementIds":["REQ-RDPS-L-AVAIL"]},{"clause":"R.4.3.1","title":"Data authenticity of interactions received from the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-AUTH"]},{"clause":"R.4.3.2","title":"Integrity of interactions received from the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-INTEG"]},{"clause":"R.4.3.3","title":"Confidentiality of data exchanged with the local product side","side":"rdps","requirementIds":["REQ-RDPS-R-CONF"]},{"clause":"R.4.3.4","title":"Availability","side":"rdps","requirementIds":["REQ-RDPS-R-AVAIL"]}],"requirements":[{"id":"REQ-RDPS-L-AUTH","side":"local","family":"Data authenticity of interactions received from the RDPS side","requirement":"Before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the local product side shall:\n\n* verify that the interaction originates from the intended RDPS-side endpoint using mechanisms that provide assurance of origin commensurate with the security needs of the function, and\n* detect and reject replayed or stale interactions where replay or reuse could affect secure operation.","rationale":"This requirement consolidates origin assurance and, where needed, replay protection into a single requirement.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies origin assurance for relevant received interactions using mechanisms commensurate with the security needs of the function and rejects replayed or stale interactions where required.","preparation":"- the RDPS-dependent product function;\n- the relevant RDPS-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the intended RDPS-side endpoint for those interactions;\n- the mechanism used by the local product side to determine or verify the origin of the received interaction;","activities":"- inspect the design and configuration of the mechanism used by the local product side to verify the origin or data authenticity of the relevant interaction;\n- verify that the origin or authenticity check is performed before the interaction is acted upon;\n- verify that interactions from the intended RDPS-side endpoint are accepted;\n- verify that interactions not originating from the intended RDPS-side endpoint, or lacking required assurance of origin, are rejected or not acted upon;\n- where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.","verdict":"Pass:\n\n- the local product side verifies origin or data authenticity of the relevant interaction before acting upon it;\n- interactions lacking the required assurance of origin are rejected or not acted upon;\n\nFail:\n\n- the local product side acts upon a relevant interaction without verifying required origin or authenticity; or\n- the required rejection of invalid, misbound, replayed, or stale interactions is not enforced.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-L-INTEG","side":"local","family":"Integrity of interactions received from the RDPS side","requirement":"The local product side shall verify that a received interaction has not been modified, substituted, corrupted, injected, or replayed in an unauthorized manner using integrity-protection mechanisms before acting upon it in a way that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function.","rationale":"This requirement provides stronger protection by requiring cryptographic integrity protection bound to the authenticated source, protects against loss of integrity of received interaction content, and protects from unauthorized modification or substitution of received interactions.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side verifies integrity of relevant received interactions using mechanisms commensurate with the security needs of the function and rejects modified, substituted, corrupted, injected, duplicated, or replayed interactions where required.","preparation":"- the RDPS-dependent product function;\n- the relevant RDPS-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the mechanism used by the local product side to detect modification, substitution, corruption, injection, duplication, or replay as applicable;","activities":"- inspect the design and configuration of the integrity-protection mechanism used by the local product side;\n- verify that integrity verification is performed before the interaction is acted upon;\n- verify that a valid interaction is accepted;\n- verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon;\n- verify that integrity protection is bound to the authenticated source where required, and that replayed or duplicated interactions are rejected where replay or reuse could affect secure operation.","verdict":"Pass:\n\n- the local product side verifies integrity of relevant interactions before acting upon those interactions;\n- modified, substituted, corrupted, injected, duplicated, or replayed interactions are rejected or not acted upon where required;\n\nFail:\n\n- the local product side acts upon a relevant interaction without verifying required integrity; or\n- the required rejection of altered, invalid, misbound, duplicated, or replayed interactions is not enforced.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-L-CONF","side":"local","family":"Confidentiality of data exchanged with the RDPS side","requirement":"The local product side shall protect the confidentiality of data during exchange with the RDPS side where disclosure of data exchanged with the RDPS side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function.","rationale":"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.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that, where disclosure of exchanged data could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the local product side protects the confidentiality of that data during exchange with the RDPS side.","preparation":"- the RDPS-dependent product function;\n- the relevant RDPS-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk;\n- the mechanism used by the local product side to protect confidentiality during exchange;","activities":"- inspect the design and configuration of the confidentiality-protection mechanism used by the local product side;\n- verify that the identified data is protected during exchange;\n- verify that data designated as requiring confidentiality is not exchanged in an unprotected manner;","verdict":"Pass:\n\n- the local product side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk;\n- such data is not exchanged in an unprotected manner;\n\nFail:\n\n- the local product side exchanges relevant confidential data without the required confidentiality protection; or\n- protected data is disclosed to an unintended endpoint.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-L-AVAIL","side":"local","family":"Availability","requirement":"The local product side shall detect unavailability of the RDPS side or unacceptable delay of an expected interaction where the availability or timeliness of interactions received from the RDPS side is necessary for the secure operation of the concerned product function, and apply a defined behaviour for the concerned product function.\n\n> NOTE 1: The defined behaviour may include, as defined for the concerned product function, denial of the affected interaction, limitation of the affected function, entry into a defined degraded mode, or transition to a secure state.\n\n> NOTE 2: Examples of such conditions include loss of connectivity to the RDPS side, failure to receive an expected response within the acceptable time, or repeated timeout of interactions required for the concerned product function.","rationale":"Where secure operation of the concerned product function depends on the availability or timely receipt of RDPS-side interactions, the local product side needs to detect unavailability or unacceptable delay and respond in a defined and secure manner.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the local product side detects unavailability, unacceptable delay, or intolerable degradation of required RDPS-side interactions, and applies a defined behaviour, including recovery or continuity measures where necessary.","preparation":"- the RDPS-dependent product function;\n- the relevant RDPS-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the acceptable timing or service conditions for those interactions;\n- the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded;\n- the degraded behaviour, secure state, recovery support, or continuity mechanism required by the selected requirement.","activities":"- inspect the design and configuration of the timeout, timeliness, degradation-detection, or equivalent controls used by the local product side;\n- verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected;\n- verify that a defined behaviour is applied when such conditions occur;\n- verify that a defined degraded behaviour or secure state is applied where required;\n- verify that recovery support is available and can be used to restore secure operation where required.\n- where failover, redundancy, or equivalent resilience is required, verify that continuity of operation is supported when the primary interaction path becomes unavailable, delayed, or degraded.","verdict":"Pass:\n\n- the local product side detects the specified failure, delay, or degradation conditions;\n- a defined behaviour is applied when the identified conditions occur;\n- recovery or continuity support is available and effective where required.\n\nFail:\n\n- the local product side does not detect the relevant failure, delay, or degradation condition; or\n- the required defined behaviour, recovery support, or continuity mechanism is absent or ineffective.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-R-AUTH","side":"rdps","family":"Data authenticity of interactions received from the local product side","requirement":"Before acting upon a received interaction that can influence the behaviour, state, configuration, or security of the RDPS-dependent product function, the RDPS side shall:\n\n* verify that the interaction originates from the intended local product-side endpoint using mechanisms that provide assurance of origin commensurate with the security needs of the function, and\n* detect and reject replayed or stale interactions where replay or reuse could affect secure operation.","rationale":"This requirement protects against acceptance of interaction content whose claimed source or origin is not genuine.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies origin assurance for relevant received interactions using mechanisms commensurate with the security needs of the function and rejects replayed or stale interactions where required.","preparation":"- the RDPS-dependent product function;\n- the relevant local product-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the intended local product-side endpoint for those interactions;\n- the mechanism used by the RDPS side to determine or verify the origin of the received interaction;","activities":"- inspect the design and configuration of the mechanism used by the RDPS side to verify the origin or data authenticity of the relevant interaction;\n- verify that the origin or authenticity check is performed before the interaction is acted upon;\n- verify that interactions from the intended local product-side endpoint are accepted;\n- verify that interactions not originating from the intended local product-side endpoint, or lacking required assurance of origin, are rejected or not acted upon;\n- where replay or reuse could affect secure operation, verify that replayed or stale interactions are detected and rejected.","verdict":"Pass:\n\n- the RDPS side verifies origin or data authenticity of the relevant interaction before acting upon it;\n- interactions lacking the required assurance of origin are rejected or not acted upon;\n\nFail:\n\n- the RDPS side acts upon a relevant interaction without verifying required origin or authenticity; or\n- the required rejection of invalid, misbound, replayed, or stale interactions is not enforced.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-R-INTEG","side":"rdps","family":"Integrity of interactions received from the local product side","requirement":"The RDPS side shall use integrity-protection mechanisms to verify that a received interaction has not been modified, substituted, corrupted, injected, or replayed in an unauthorized manner before acting upon it if that interaction could influence the behaviour, state, configuration, or security of the RDPS-dependent product function.","rationale":"This requirement protects against loss of integrity of received interaction content.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side verifies integrity of relevant received interactions using mechanisms commensurate with the security needs of the function and rejects modified, substituted, corrupted, injected, duplicated, or replayed interactions where required.","preparation":"- the RDPS-dependent product function;\n- the relevant local product-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the mechanism used by the RDPS side to detect modification, substitution, corruption, injection, duplication, or replay as applicable;","activities":"- inspect the design and configuration of the integrity-protection mechanism used by the RDPS side;\n- verify that integrity verification is performed before the interaction is acted upon;\n- verify that a valid interaction is accepted;\n- verify that modified, substituted, corrupted, or injected interactions are rejected or not acted upon;\n- verify that integrity protection is bound to the authenticated source where required, and that replayed or duplicated interactions are rejected where replay or reuse could affect secure operation.","verdict":"Pass:\n\n- the RDPS side verifies integrity of relevant interactions before acting upon those interactions;\n- modified, substituted, corrupted, injected, duplicated, or replayed interactions are rejected or not acted upon where required;\n\nFail:\n\n- the RDPS side acts upon a relevant interaction without verifying required integrity; or\n- the required rejection of altered, invalid, misbound, duplicated, or replayed interactions is not enforced.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-R-CONF","side":"rdps","family":"Confidentiality of data exchanged with the local product side","requirement":"Where disclosure of data exchanged with the local product side could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side shall protect the confidentiality of that data during exchange with the local product side.","rationale":"This requirement ensures confidentiality where disclosure of exchanged data could affect the security or secure operation of the RDPS-dependent product function.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that, where disclosure of exchanged data could lead to unacceptable cybersecurity risk for the RDPS-dependent product function, the RDPS side protects the confidentiality of that data during exchange with the local product side.","preparation":"- the RDPS-dependent product function;\n- the relevant local product-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the categories of exchanged data for which disclosure could lead to unacceptable cybersecurity risk;\n- the mechanism used by the RDPS side to protect confidentiality during exchange;","activities":"- inspect the design and configuration of the confidentiality-protection mechanism used by the RDPS side;\n- verify that the identified data is protected during exchange;\n- verify that data designated as requiring confidentiality is not exchanged in an unprotected manner;","verdict":"Pass:\n\n- the RDPS side protects the confidentiality of exchanged data where disclosure could lead to unacceptable cybersecurity risk;\n- such data is not exchanged in an unprotected manner;\n\nFail:\n\n- the RDPS side exchanges relevant confidential data without the required confidentiality protection; or\n- protected data is disclosed to an unintended endpoint.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}},{"id":"REQ-RDPS-R-AVAIL","side":"rdps","family":"Availability","requirement":"The RDPS side shall detect unavailability of the local product side or unacceptable delay of an expected interaction and apply a defined behaviour for the concerned product function where the availability or timeliness of interactions received from the local product side is necessary for the secure operation of the concerned product function.\n\n> NOTE 1: The defined behaviour may include, as defined for the concerned product function, rejection of the affected interaction, limitation of the service, termination of the affected exchange, or transition of the affected interaction to a secure state.\n\n> NOTE 2: Examples of such conditions include loss of connectivity to the local product side, failure to receive an expected request or input within the acceptable time, or repeated timeout of interactions required for the concerned product function.","rationale":"Where secure operation of the concerned product function depends on the availability or timely receipt of local product-side interactions, the RDPS side needs to detect unavailability or unacceptable delay and respond in a defined and secure manner.","applicability":{},"assessment":{"objective":"The objective of the assessment is to verify that the RDPS side detects unavailability, unacceptable delay, or intolerable degradation of required local product-side interactions, and applies a defined behaviour, including recovery or continuity measures where necessary.","preparation":"- the RDPS-dependent product function;\n- the relevant local product-side interactions that can influence the behaviour, state, configuration, security, or availability of that function;\n- the acceptable timing or service conditions for those interactions;\n- the defined behaviour to be applied when the required interactions are unavailable, delayed, or degraded;\n- the degraded behaviour, secure state, recovery support, or continuity mechanism required by the selected requirement.","activities":"- inspect the design and configuration of the timeout, timeliness, degradation-detection, or equivalent controls used by the RDPS side;\n- verify that unavailability, unacceptable delay, or intolerable degradation of required interactions is detected;\n- verify that a defined behaviour is applied when such conditions occur;\n- verify that a defined degraded behaviour or secure state is applied where required;\n- verify that recovery support is available and can be used to restore secure operation where required.\n- where failover, redundancy, or equivalent resilience is required, verify that continuity of operation is supported when the primary interaction path becomes unavailable, delayed, or degraded.","verdict":"Pass:\n\n- the RDPS side detects the specified failure, delay, or degradation conditions;\n- a defined behaviour is applied when the identified conditions occur;\n- recovery or continuity support is available and effective where required.\n\nFail:\n\n- the RDPS side does not detect the relevant failure, delay, or degradation condition; or\n- the required defined behaviour, recovery support, or continuity mechanism is absent or ineffective.","evidence":"- design and configuration evidence for the relevant protection mechanism;\n- evidence showing acceptance or normal processing of valid interactions;\n- evidence showing rejection, non-processing, protected exchange, recovery, or continuity behaviour for invalid or failure conditions, as applicable.","guidance":""}}]},"threats":[{"id":"TH-UEVU","title":"Unknown exploitable vulnerabilities","description":"Attacker may use unknown exploitable vulnerabilities in the product to harm the product's assets."},{"id":"TH-KEVU","title":"Known exploitable vulnerabilities","description":"Attacker may use known exploitable vulnerabilities in the product implementation to get unauthorized access to product assets."},{"id":"TH-CACC","title":"Circumvention of access control","description":"Attacker may get unauthorized access to product assets by exploiting gaps or weaknesses in authorization or access control."},{"id":"TH-DSTP","title":"Unauthorized access to data stored","description":"Attacker may get unauthorized access to confidential data stored on the product through acquisition of a used platform containing the product."},{"id":"TH-UADT","title":"Unauthorized access to data transmitted","description":"Attacker may use access to the connected network to compromise the confidentiality or integrity of data transmitted by the product."},{"id":"TH-CONF","title":"Access to assets via configuration errors","description":"Attacker may use unintentional configuration errors to get unauthorized access to the product assets."},{"id":"TH-AVAI","title":"Denial of service attack on product","description":"Attacker may use network access to product to reduce availability of product functions."},{"id":"TH-DDOS","title":"Interference with other devices","description":"Attacker may use product functions to interfere with other devices or services."}],"draftGaps":["Table 5.1-1 spells one MON_LOG level \"meidum\" (UC-2-ENTER-L); read as \"medium\".","SU_UPDATES-3: the Objective field of clause 6.5.3 is empty in this interim draft (the label is present with no text).","CYB_OPS-10: clause 6.2.10 carries no assessment block — it delegates assessment to Annex R (\"This assessment is done based on the definitions in the Annex R.\"). Assess it through the Annex R requirement entries.","Annex K defines no requirement ids of its own: the four entries under \"Annex K — Cryptography\" are Vandorisk handles (REQ-K-*) for the draft's clauses K.1.1, K.3.1, K.4.1 and K.2.1, each carrying its verbatim text and the assessment case the draft assigns to it (K.1.2.1-3, K.2.2).","Annex K tables K.1 (ACM-extended) and K.2 (interoperability-based mechanisms) are empty placeholder templates in this interim draft — the draft lists no concrete mechanisms yet.","Annex R of this draft defines ONE requirement per family and side (REQ-RDPS-L-AUTH, -L-INTEG, -L-CONF, -L-AVAIL and the four REQ-RDPS-R-* counterparts) — unlike the SIEM draft there are no alternative -001/-002/-003 rigor levels to choose between.","Annex R clause R.6's table heading reads \"Mapping of CRA Annex I to EN 304 620 Annex R requirements\" — an editorial slip in this interim draft (the annex belongs to EN 304 621).","Clause 5 writes the third secure-by-default requirement as \"SBD-TECH-3\"; clause 6 and Table 5.1 use SBD_TECH-3. Loaded as SBD_TECH-3.","INT_CONF-1 requires implementing CON_CHANNEL-6, an id the draft never defines (clause 5.7 stops at CON_CHANNEL-5) — a dangling cross-reference in this interim draft.","AP_HA-7 and EMM_ROUTE-1 reference CYB_OPS-1, and a clause 5.11 note references CYB_OPS-2; the draft's CYB_OPS requirements are numbered 8-10, so these are stale cross-references (most plausibly to CYB_OPS-8/-9).","Notes and Annex G refer to \"SU_UPDATE-2\"/\"SU_UPDATE-3\" (missing S) for SU_UPDATES-2/-3, Annex G to \"INT_ROTATE-1\" (the set starts at INT_ROTATE-4) and \"MON_METRICS-4\" (the set starts at MON_METRICS-14), and 6.5.4 to \"CON_CRYPO-1\" (CON_CRYPTO ids start at -3): editorial slips left as-is in the quoted text.","Clause 6 numbering slips in this interim draft: 6.5.14 is used for both SU_UPDATES-14 and SU_UPDATES-15, and 6.14.1 appears twice (a stray \"Logging tests\" heading before MON_LOG-1). Blocks are keyed on requirement ids, not clause numbers.","Annex A maps only CRA Annex I Part 1: this interim draft carries no correspondence table for Part 2 (vulnerability handling). Those obligations remain assessed through the horizontal CRA pack (II.1–II.8)."]}