Asset Identification for Admin UI–Configurable Security Components in SD-WAN Architectures (EN 18031)

[Roger2625]

Hello,

I am performing EN 18031 testing on an SD-WAN device, where most configuration and management functions are handled via a cloud-based orchestrator, rather than directly on the device UI.

Inside the solution, I observe the following characteristics:

The physical SD-WAN device DUT has limited local UI.

Most administrative actions (policy configuration, routing, firewall rules, firmware updates, user management, etc.) are performed through the cloud orchestrator.

The device primarily acts as an execution and forwarding component, receiving configuration from the orchestrator.

When accessing the Administrative Web UI / Orchestrator UI, I can log in as an administrator and configure the following security-related components:

Authentication Engine
RBAC Authorization Engine
Session Management Engine
Admin / User Passwords
Password Complexity Policy
Account Lockout Threshold
MFA Configuration
API Tokens / Keys
My current understanding is:

Although these components are visible and configurable via the Admin UI, they represent authentication and authorization mechanisms or policies, not standalone assets.

EN 18031 follows an asset-based approach, focusing on assets exposed via interfaces, rather than testing internal security engines or policy logic.

Therefore, these mechanisms should not be tested directly as assets.

The actual assets are the interfaces and management capabilities that expose control over the system, such as:

Administrative Web UI (device or orchestrator)

SD-WAN device management and configuration functions

Network interfaces and services on the device

Configuration, control, and update channels between orchestrator and device

Key questions regarding asset identification and scope:

When security components (authentication engine, RBAC, session management, passwords, MFA, etc.) are configured via the Admin UI, is it correct to treat:

The Administrative Web UI and the management functions it exposes as the asset, and

The listed security components only as access control mechanisms, not as standalone assets?

In an SD-WAN architecture where configuration and control are primarily handled by a cloud orchestrator, should EN 18031 testing:

Focus only on the physical device (DUT), or

Also include the cloud orchestrator, since it acts as the primary administrative interface and asset exposure point?

If the orchestrator is mandatory for operation, should it be considered:

Part of the DUT ecosystem and therefore in scope for asset identification and ACM-1 / ACM-2 testing, or

An external system, with testing limited to the device-side interfaces and communication channels?

Is it correct that testing should focus on:

Whether unauthorized entities can access or misuse exposed interfaces and functions (Admin UI, APIs, control channels, update mechanisms),

Rather than testing the internal behavior or implementation of authentication engines, RBAC logic, password policies, account lockout, or MFA mechanisms themselves?

I would appreciate clarification on how EN 18031 expects asset identification, asset scope, and responsibility boundaries to be defined in SD-WAN deployments that rely heavily on cloud orchestrators.

Thank you!

[zealience]

Hello @Roger2625 ,

Thank you for your question. I understand that you are testing an SD-WAN device. Keep in mind that EN 18031 only focuses on radio equipment in scope of the RED DA. In your case, this means that only the SD-WAN device needs to comply, and therefore needs to be tested.

To answer your questions regarding assets, I would highly recommend reading our articles on network/security/privacy assets. Please note that interfaces are not regarded as assets. It is important to keep in mind the definitions provided in the standard.

Regarding testing, everything that needs to be assessed is laid out in the standard itself. You can refer to our article EN 18031 & RED Cybersecurity Compliance Guide for IoT Manufacturers, section Performing EN 18031 Assessments. Please note that it's not just the assets that must be assessed. Depending on the requirement, you may need to assess interfaces, or mechanisms like authentication mechanisms. Refer to the assessment units for each requirement.

You can use our test plan template to guide your testing activities. Keep in mind that ultimately, what drives the testing is the technical documentation created by the manufacturer. For each requirement of EN 18031, you will perform the necessary assessments on what has been documented. For example, for ACM-1, you need to assess the assets which have been documented as being accessible by entities (e.g., security asssets listed under the identifier [E.Info.ACM-1.SecurityAsset]).

I hope this helps. Best of luck with the testing!
Guillaume