What Manufacturers Must Do to Meet EN 18031 (RED DA) Vulnerability Management Requirements
- Arianna Gringiani
- Apr 30
- 5 min read
Published on: April 30, 2025
Estimated reading time: 6 minutes
Starting August 1, 2025, the cybersecurity requirements of the RED Delegated Act (RED DA) will become mandatory for all radio internet-connected devices placed on the EU market. To support implementation, the EN 18031 standard series has been developed. See our previous blog post: RED DA and CRA: How the Newest EU Cybersecurity Legislations Impact Your Products
In this blog post, we focus on one of the most complex requirements of the standard:
[GEC-1] Up-to-date software and hardware with no publicly known exploitable vulnerabilities.
As the requirement is unpacked in the standard, it brings up several points that are not straightforward. The first question that comes up is: what does it mean for a vulnerability to be “publicly known exploitable”?
But that’s just the beginning. To apply the requirement, manufacturers are also expected to describe all software and hardware components used in a product, and keep track of known vulnerabilities over time.
In the following sections, we go through these points and show how they can be addressed within the EN 18031 approach - supported by our product security management platform, ARIANNA.
What are "publicly known exploitable vulnerabilities”?
The requirement in EN 18031 states:
The equipment shall not include publicly known exploitable vulnerabilities that, if exploited, affect security assets and network assets.
However, the term publicly known exploitable vulnerability is not officially defined in existing vulnerability databases. It’s a new expression introduced by the standard itself, and it can be difficult to determine what qualifies.
To clarify its intent, EN 18031 lists several factors that manufacturers should consider when evaluating whether a vulnerability falls under this category. These factors can include, but are not limited to:
the existence of public proof-of-concept or known exploits, or evidence of active exploitation.
the attack surface of the device and vectors/paths by which an attacker can gain access to the device to exploit the vulnerability
the security mechanisms built into the device;
the intended functionality of the equipment;
the expected operational environment and any external security controls.
ARIANNA supports device manufacturers with this analysis - the platform supports automation and marks vulnerabilities in this category directly as ‘High Priority’.
Still, it’s up to the manufacturer to complete the assessment. Deciding whether a vulnerability is truly exploitable depends on how the device is supposed to work and is something that cannot be fully automated, but the process can be made significantly easier.
How to know which components are affected?
Understanding which vulnerabilities matter is one thing, but that assumes you already have a list of the vulnerabilities that may be present in your product. However, identifying vulnerabilities is a separate challenge on its own. To even begin the process, you need to know which components are included in the device.
The Software Bill of Materials
The Software Bill of Materials EN 18031 requires the device manufacturer to create and maintain a list of software components, which is called a Software Bill of Materials (SBOM):
To facilitate software vulnerability monitoring, the manufacturer of the equipment keeps technical documentation of the software of the equipment, including both open-source software and commercial off the shelf components.
An SBOM is a structured list of all software components included in a device, including open-source packages, libraries, binaries, and off-the-shelf software. For more background, see our previous post: All you need to know about SBOM Management.
Having a precise list of components is a prerequisite for vulnerability detection. To understand if your device is affected by a vulnerability, it is paramount that you are able to list all the components in the device.
This is especially relevant given that a large portion – up to 98% – of the software in connected devices comes from third-party sources. And vulnerabilities are most often found in these external components.
That said, producing a reliable SBOM isn’t trivial. Missing components, inconsistent naming, and wrong component versions, can easily lead to errors. An incomplete or inaccurate SBOM leads to missed vulnerabilities or false positives.
This is why we take a careful approach to SBOM creation within ARIANNA, providing specific tools designed to ensure consistency and accuracy across different types of firmware and software packages.
The Hardware Bill of Materials
The quote from the standard in the previous section continues:
…Likewise, technical documentation of hardware can assist in the identification of the hardware vulnerabilities.
In other words: alongside the SBOM, manufacturers should also maintain a Hardware Bill of Materials (HBOM). Hardware components can be affected by vulnerabilities just like software, and tracking them is just as important.
However, most tools on the market that support vulnerability monitoring focus only on the SBOM. The HBOM is often left out, even though it is explicitly mentioned in EN 18031.
In ARIANNA, we treat software and hardware components as part of the same picture. SBOM and HBOM together make up the device model, which is the basis for comprehensive vulnerability monitoring.
How to identify vulnerabilities?
So now, assume you have a complete device model of your product, meaning both SBOM and HBOM are available and accurate. The next step is identifying vulnerabilities: this means going through each component in the device model and checking it against public vulnerability databases, such as the NIST National Vulnerabilities Database and existing National European Vulnerabilities Databases.
For each matching vulnerability, you then need to assess whether it qualifies as “publicly known exploitable,” based on the criteria we discussed earlier.
And the most challenging part: this isn’t something you do once. New vulnerabilities are discovered every day, and existing vulnerabilities are constantly adjusted or enriched, so the process needs to be continuous. It’s demanding: time-consuming, error-prone, and costly. As a typical device can have hundreds or even thousands of relevant vulnerabilities, doing this manually is simply not realistic. That’s why ARIANNA is designed to automate this process.
How Do I Treat Vulnerabilities?
Let’s look at another extract from EN 18031. In the “required information” section, the standard says:
[...] a justification is given for each vulnerability that affects network assets and security assets about the remediation, mitigation and non-exploitation of the listed hardware or software publicly known exploitable vulnerabilities.
It’s important to understand that not all vulnerabilities need to be fixed. Updates are costly to develop and deliver, so you want to release them only when necessary.
It’s the smaller group of “publicly known exploitable” vulnerabilities that require action.
This means that once you have identified the exploitable vulnerabilities and assessed which ones may actually impact your product, you need to justify how you treat them - and possibly fix them.
Some vulnerabilities do not pose a real risk in the context of a specific device, and can be accepted after proper evaluation.
Knowing which vulnerabilities need to be addressed and which of them have a patch or a mitigation available helps you schedule security updates efficiently.
Vulnerability Management Process
To recap, the process we’ve described is made of several steps:
Build an accurate device model (SBOM + HBOM)
Identify vulnerabilities based on that device model
Prioritize vulnerabilities by selecting the ‘exploitable’ vulnerabilities
Remediate or mitigate those vulnerabilities with security updates, or by removing the component
Together, these steps form a proper vulnerability management process. And this process should not stop when the product is placed on the market: it has to be repeated over time, to keep the product secure against new threats.
Schedule a Demo
Want to see the ARIANNA Product Security Management Platform in Action? Contact us to schedule a one-hour demo and discuss your specific use case.
Discover how device manufacturers ensure the cybersecurity and compliance of their interconnected products throughout various teams, business sectors, and stages of their lifecycle.
Komentarze