Identify vulnerabilities and document them for auditing
In this article, we will look at how to structure an approach to vulnerability research that is consistent with EN 18031, focusing on methodology, evidence, and testing, leaving aside the list of specific tools to be used.
On August 1, 2025, the cybersecurity requirements set out in Directive RED 2014/53/EU (Art. 3(3) d/e/f) came into force for specific categories of radio equipment, as established by Delegated Regulation (EU) 2022/30.
The EN 18031 standard was designed to demonstrate that radio equipment, together with the ecosystem that supports it (apps, cloud, APIs), adequately protects:
the network and its resources (Art. 3(3)(d))
personal data and privacy (Art. 3(3)(e))
the prevention of fraud in transfers of value or virtual currency (Art. 3(3)(f))
When a laboratory or assessor examines vulnerability management, it typically verifies that the organization has:
the ability to identify known vulnerabilities (CVE, supply chain) prior to product release
the ability to detect its own vulnerabilities (bugs, misconfigurations, design issues)
a post-market process to manage them effectively (triage, correction, secure updates, defined timelines, documentation of evidence)
This approach mirrors the operational guidelines that accompany EN 18031 testing, where there must be a balanced combination of testing, documentation, and organizational readiness.
To make the analysis truly effective, it is useful to distinguish vulnerabilities into four main categories. Each requires specific detection techniques:
1 - Vulnerable dependencies (CVE)
Open source libraries, SDKs, third-party components, container images, cryptographic libraries, and the like.
2 - Application code bugs
Injection, authentication bypass, unsafe deserialization, path traversal, inadequate error handling, and so on.
3 - Configuration vulnerabilities and runtime exposure
Weakly configured TLS, unnecessarily exposed APIs, incorrect cloud configurations, active unused ports or services, accessible debug interfaces.
4 - Parsing and protocol vulnerabilities
Crashes, memory corruption, bugs triggered by malformed inputs, particularly common in embedded and IoT devices.
To meet the requirements of EN 18031, you must demonstrate reasonable coverage of all areas that may have an impact on networks, data, and economic value.
A) SCA on SBOM: identifying public and known vulnerabilities
The SBOM (Software Bill of Materials) represents the bill of materials for the software: it lists components, versions, and dependencies in a structured way.
In practice, the process works as follows: an SBOM is generated for each release, analysed using Software Composition Analysis (SCA), and a list of CVEs (Common Vulnerability Exposures) that impact the product is obtained.
For EN 18031, the SBOM is particularly valuable because it produces clear and traceable evidence:
release X → SBOM generation → CVE report → triage → correction/mitigation → release X+1
Although the SBOM is not an explicit requirement of the standard, it is one of the most solid pieces of evidence to demonstrate that a product with unmanaged known CVEs is not being placed on the market. The EN 18031-oriented checklists and readiness guides focus precisely on having a structured process and accurate documentation.
B) SAST: identifying bugs in the code before they become exploits
Static code analysis is used to detect recurring vulnerability patterns: injection, validation errors, hardcoded credentials, and incorrect use of encryption.
The main advantage is the ease of integration into continuous integration flows: pull request → scan → correction → new scan
From a methodological point of view, it is worth mentioning ETSI TR 104 117, which explicitly mentions the use of tools and processes to assess security and resilience in the context of the risk and vulnerability ecosystem.
C) DAST: testing APIs and applications from the outside
Dynamic analysis, often combined with manual testing, allows you to identify: authentication and authorisation bypasses, weak session management, lack of rate limiting (exposure to brute force attacks), and input validation errors on real endpoints.
This component is particularly aligned with EN 18031 because it demonstrates network and data protection through realistic tests, documented by logs and traces of requests/responses.
D) Fuzzing: the often overlooked technique (with costly consequences)
Fuzzing applied to parsers and protocols, even internal ones, is often the most effective method for detecting crashes and denial of service, parsing bugs, and memory corruption (particularly critical in C/C++/embedded environments).
An important message to convey: if the product includes radio stacks/protocols or complex parsing, the absence of fuzzing represents a significant gap in security test coverage.
E) Hardening review: vulnerabilities without bugs
This category covers issues that directly impact requirements (d) and (e) of the RED, even though they are not actual bugs: unnecessary but exposed services, weak TLS/cipher/protocol configurations, unprotected debug interfaces, and inconsistent password and authentication policies.
One aspect to keep in mind: the restrictions applied by the Commission to the publication of EN 18031 highlight some particularly sensitive points (e.g., aspects related to passwords and access control) where presumption of conformity is not automatic.
The HBOM (Hardware Bill of Materials) is very useful when it comes to radio equipment, because it is essential for checking:
variants and SKUs (different SoCs, radio modules, and secure elements involve different attack surfaces)
specific vulnerabilities of chipsets and modules (Wi-Fi, Bluetooth, modems)
"as-built" traceability (what was actually assembled on a specific production batch)
For those looking for a reference on the supply chain front, CISA's HBOM framework offers a good conceptual basis, without this implying that EN 18031 explicitly requires it.
To structure a verifiable and documentable approach, it can be useful to follow a logical framework that links objectives, controls, evidence, tests, and final outputs.
Post-market vulnerability management
With EN 18031, the work does not end with the affixing of the CE marking. It is necessary to ensure:
continuous monitoring of vulnerabilities (CVE, supplier advisories)
a channel for receiving reports (PSIRT or coordinated disclosure system)
the ability to release fixes through secure updates
complete and traceable documentation of all these activities
The operational guidelines related to EN 18031 emphasize this integrated vision: a structured process, verifiable testing, and accurate documentation as fundamental pillars.
Finding and managing all vulnerabilities in compliance with EN 18031 is very complicated and costly, both in terms of money and time. It requires specific skills, a lot of time, and documentation that will stand up to audit.
For many companies, especially those without an internal security team, coordinating SBOM, SCA, SAST, DAST, fuzzing, and hardening reviews quickly becomes a problem that blocks the product's release to market.
But there is a way to make all this more manageable.
RedComply is an artificial intelligence-based platform that we built for this very purpose: to make EN 18031 and RED Cybersecurity compliance easier and faster.
Automatic SBOM generation
The platform automatically creates the SBOM (Software Bill of Materials) for your project, whether you are working on software for standard processors or firmware for embedded microcontrollers.
Once the SBOM is ready, RedComply automatically identifies all known vulnerabilities (CVEs) in the components you are using and guides you through the regulatory requirements necessary for compliance.
What would normally take weeks of work is reduced to a few days, with a time reduction of up to 93%!
Already have an SBOM? No problem
If you have already generated an SBOM with other tools, you can upload it directly to the platform. We support several standard formats, and from there, vulnerability analysis and the path to compliance can begin immediately.
Let us help you!
Visit redcomply.com or contact us directly to discover how to automate the process of vulnerability discovery and EN 18031 compliance to reduce certification time and costs.