Made a number of typographic corrections and clarifications to all use cases. ...

The above given example architecture of figure 3 can serve as explanation help during the conformity assessment to meet CRA [\[i.1\]](#_ref_i.1) Annex I part 1.

>NOTE: This use case seems to focus on two security functions of IoT products, but make sno distinctions btween large and small IoT networks (with corresponding botnet risks) or products designed for higher risk environments (e.g. home "convienance" devices such as a set of speakers < home essential devices such as lighting < enterprise and industrial deployments such as warehouse or factory lighting and < hiogh risk infrastructural device/environments such as freezer units at a large scale meat storage facitility.) To me these levels of risk reprsent sub use cases and maybe lesser requirements/mitigations for low risk/impace devices? Additionally the degree of remote sertvice involved in the NMS may also create sub clasess (or potentially it could be modelled as a risk factor?) 

#### 4.4.1.2 Home network deployment

![Figure 4.4.1.2-1: Home network deployment](./media/2025-08-10_homenetwork.drawio.png)

**Figure 4.4.1.2-1: Home network deployment**

In this use case, connectivity for the user's home is provided by an access point mkaing the upstream connection technology transparent to the user. Access 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 user's home.

In this use case, the network manangement system controls the user's home network of devices and an access point providing connectivity for the user's home to outside networks, usually public.  Access 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 user who requests service's home. An access point also make the upstream connection technology transparent to the user through the NMS.

The NMS is either locally installed on the access point device, running on a different device within the same network, or a RDPS. All varities of home deployment 

The NMS in this use case is most often locaslly installed on the access point device but may be running on a different device within the same network, or as a remote service, an RDPS.

The local access point can serve multiple devices in the same network and provide supporting services like DHCP and DNS caching. The minimum of supporting services 

Provided supporting services can be bare minimum, but they can include remote connectivity options like VPN server depending on the product.

The access point devices actrively send metrics to the NMS and can serve multiple devices in the same network.  Acces point devices also provide supporting services like DHCP and DNS caching, but beyond such a minimum they can offer more extensive services such as remote connectivity options like VPN server depending on the product.

The device actively sends metrics towards the NMS where from the user can perceive the operation of the device and can control the configuration which is set to the device.

Commonly, user does this with a browser, but other implementations can rely on command-line interface, for example.

Meterics from the access point and other deives within the home network are forwarded to the NMS, where the user can percieve these meterics and control the configuration of each networked device.  In many deployments actual configuration control and review of metrics collected by ther NMS is achieved with an additional service or alternate piece of software, most often a browser, but sometimes is other ways, such as through a command-line interface. 

### 4.4.2 Multi-user deployment

-   The network connects to other single user devices and also a number of distant or local other networks with even more spread user devices.

-   The network connects to a broad variety and large number of devices, including single user devices and a number of distant or local other networks themseles connected to other user devices.

-   Users and connected networks are usually distant and outside controlled operational environments.

-   High number of elements

-   Significant size of affected Service Requesting Users base

-   Deployment has a high number of elements.

-   User base is of significant size, and the number of users and network functions affected by compromise of failure of the NMS is potentially high.

#### 4.4.2.1 Enterprise network

![Figure 4.4.2.1-1: Enterprise network](./media/2025-08-10_office.drawio.png)

#### 4.4.2.1 Office network

**Figure 4.4.2.1-1: Enterprise network**

![Figure 4.4.2.1-1: Office network](./media/2025-08-10_office.drawio.png)

A typical enterprise or office network has multpiple service requesting users connecting simultaneously to a shared infrastructure.

**Figure 4.4.2.1-1: Office network**

Infrastructure may include multiple sites connected through a vareity 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. An also office network also typically operates for long periods, developing layered history of past versions and functions. 

A typical office network has multpiple service requesting users connecting simultaneously to a shared infrastructure.

There can be multiple sites, that can be interconnected through: internet, dedicated routing infrastructure like IP-MPLS-tunnel, third party service provider, hyperscaler infrastructure, or 5G slicing, to name afew.

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

Typically a office network is layers of history that is accumulated through out the years of operation.

With modern remote working expectations, these neworks contain some kind of VPN or other remote connectivity options that enable working with the subset of curated services availabe only through this shared environment, intranet.

User identity verification, authorization, and the maintenance of a user is needed for each such intranet service or environment. This identity pool can be local for the service, shared within the same intranet, or provided as a service outside of the network context. In office environments, larger indentity 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 missused.

Each available intranet service has at least a single way to verify the users identity.

This identity pool can be local for the service, shared within the same intranet or provided as a service outside of the network context.

Larger number of pools provides redundancy, but can also complicate the administration of the credentials and reduce response time when leaked and missused credentials needs to be rotated out.

Whyile 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. A contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services. IdP's may be part of an NMS or seperate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS. In all varieties the nature of the IdP deplyed to the netowrk is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration methods or IdP technique.

It is possible to maintain the identities of all of available intranet services by hand, but this is often perceived as impractical even with medium sized pools of users.

A modern office network deployment has often some kind of Identity Provider (IDP) available, what most of the services are using.

How the IDP has set up in the network context is relevant to this document as it can become a major risk factor, if the product does not support a relevant integration style or technique.

>NOTE: Again this use case seems to focus on one function (IdP) rather then on the operational environment and users. It is also not strcutured like the above use cases and finally, migh tbenefit from being broken down into higher and lower risk (smaller/larger or low security data/high security data) use cases.

#### 4.4.2.2 Telecom network

**Figure 4.4.2.2-1: Telecom network**

A telecom network inherits the most of the components of an office network, with the obvious added complexity of everything.

The provided services needs to handle more load, the identity providers are often used to create segmentation and redundancy, and the routers and switches can be basesations serving thousands of users simultaneously.

A telecom network resembles an enterprise network, with the obvious added complexity throughout.

The telecom NMS will handle a greater load, including more users, devices, and identities. Identity providers (IdPs) are often used to create segmentation and redundancy, and network uses its routers and switches as base sations serving thousands of users simultaneously.

The division of northbound and southbound describes the abstraction levels, where towards south, one has the hardware that is controlled, and towards north, there are applications and users controlling the network.

The supporting services, internal and third party, are often modelled as east-westbound, depending on the objectives of the modelled architecture. In the above figure, SIEM is an example service that is adjacent to the NMS, and is often used in modern deployments.

Telecom networks are modlled by division into northbound and southbound abstraction levels or descriptors, where southbound describes traffic from the NMS and hardware controlled by the network. Northbound traffice comes from lower layers of the network such as routers and switches and from the applications and users. Services supporting and the telecom network, both internal and third party, are described has being eastbound or westbound, depending on the objectives of the modelled architecture. In the above figure, SIEM is an example service that is adjacent to the NMS, and is often used in modern deployments.

It is not uncommon to have a in-house Public Key Infrastructure (PKI), that declares it's own Certificate Authority or authorities, that are deployed to managed machines within the company.

How many, and how the CAs are used dependents on design of the network.

In telecom deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares it's own certificate authority (CA) or authorities deployed to the managed machines within the network. The number of these managed machines, number of CA's and how the CA's are used is dependent on design of the network Alternatively, even at telecom scale, and NMS can even provide its own certifactes and form an independent and segregated trust ring.

The NMS can even provide its own certifactes to the devices to form an independent and segregated trust ring.

## 4.5 Risk Factors