RED Directive cybersecurity requirements: EN 18031 series now mandatory
Requirements now in force for internet-connected radio equipment; EN 18031-1/2/3, as a harmonised standard, has become the basis of the CE declaration.
The Radio Equipment Directive (RED) introduces cybersecurity requirements for certain radio equipment under network protection, personal data protection and fraud protection. The EN 18031 series is the harmonised standard set corresponding to these requirements.
Applying the harmonised standard provides a presumption of conformity: a product assessed against the standard is deemed to meet the relevant essential requirement. Where the standard is not applied, the manufacturer must demonstrate conformity by another route.
The series is divided into different parts according to the type of device; which part applies depends on the device's function and how it processes data.
The directive's dormant articles have taken effect
Radio Equipment Directive 2014/53/EU had carried three cybersecurity protection objectives in its text for years, but they were not being applied. The Commission's delegated regulation (EU) 2022/30 made these articles applicable for certain classes of radio equipment as of 1 August 2025.
The three objectives that took effect are: 3.3(d) protection of the network, 3.3(e) protection of personal data and privacy, and 3.3(f) protection against fraud. All three can apply to the same product together, and which ones apply is determined by the product's function.
This means a new section is added to the conformity file of internet-connected radio products. The radio and EMC side does not change; a cybersecurity assessment is added alongside it.
What the EN 18031 series does
As a harmonised standard, EN 18031-1:2024 defines common security requirements for internet-connected radio equipment. EN 18031-2:2024 covers equipment processing personal data, traffic data or location data, while EN 18031-3:2024 covers equipment processing virtual currency or monetary value.
The series being harmonised gives the manufacturer that fully applies the standard a presumption of conformity: it is deemed to meet the requirements, and the file can be closed with self-declaration.
The limit of the presumption: restricted clauses
The series' presumption of conformity is not unconditional. If a product triggers one of the restricted clauses — for example, a design that lets the user skip setting a password — the automatic presumption of conformity does not arise.
When the presumption does not arise, the route passes through a notified body. This is a difference that changes both timeline and cost: a file that would have closed with self-declaration turns into a third-party assessment because of a single design choice.
This is why reading the standard's restricted clauses at the design stage is far cheaper than reading them at the test stage. Default passwords, a skippable initial setup, and the absence of an update mechanism are the most common triggers.
Why the harmonised standard matters so much
EU legislation writes the essential requirements; standards provide their technical equivalent. When a requirement takes effect but its harmonised standard has not yet been published, the manufacturer falls into a difficult path: it must demonstrate meeting the essential requirement through its own technical file or apply to a notified body.
When the harmonised standard is published, a PRESUMPTION of conformity arises: a product conforming to the standard is presumed to meet the essential requirement, and the burden of proof is reversed. The manufacturer becomes able to make its own declaration.
This is why the cybersecurity articles gaining a harmonised standard matters separately from the obligation itself: the obligation already existed, and now there is a standard way to meet it.
What the three requirement headings ask
The network protection heading requires that the product not harm the network it connects to and not misuse network resources. Weak default credentials, unnecessary open ports and unauthenticated remote access are typical findings under this heading.
The personal data protection heading requires the product to protect the personal data it processes and user privacy: encryption of data transmission, protection of local storage, and user control over their data.
The fraud protection heading requires transaction integrity and authorisation in products with a payment or value-transfer function. The three headings apply to different product groups; which heading applies to which product is a matter of scope determination.
How the evidence file is built
Cybersecurity evidence is not a measurement result; it consists of the list of applied requirements, the interfaces covered, the checks performed, and the record of how findings were remediated. A report without a scope statement cannot be read.
The items the report must record are: which hardware version, which software version, which interfaces and which configuration were tested. Evidence without version information cannot defend its validity after the next software update.
The file does not close upon placing on the market: the obligation of open monitoring and updates continues throughout the support period, and this is the living part of the technical file.
What to do?
- 1Determine which EN 18031 part your device falls under.
- 2Address security requirements at the design stage.
- 3Add the cybersecurity assessment to your technical file.
This article is for informational purposes and does not constitute legal advice. How a regulation applies to your product depends on the product's technical characteristics and target market; the exact scope can only be determined by examining the product.