Radio Equipment Directive (RED) Cybersecurity Requirements

Since 1 August 2025, anyone holding the technical file for an internet-connected radio product has carried up to three cybersecurity obligations under the Radio Equipment Directive (RED) that never applied before. They had sat in Article 3(3) since 2014, dormant until a delegated regulation switched them on with a start date of 1 August 2024. A 2023 amendment pushed that back a year while the European standards bodies finished the harmonised standards.

One year in, all three harmonised standards are cited with restrictions, and which restriction a design trips decides whether the file can be self-declared or has to go to a Notified Body. The same evidence set is also the only concrete scaffold available for the Cyber Resilience Act (CRA) file that will eventually replace it. The CRA’s own dates are already fixed, but the date the RED cybersecurity layer switches off hasn’t been published.

This guide covers what the directive actually requires, then the EN 18031 restrictions that still force a Notified Body and the technical file that has to survive the handover. A stale EN 18031 rationale record is a problem twice over, and the first thing to settle is which of the three obligations your product carries.

What the Radio Equipment Directive Requires

The RED sets three tiers of essential requirement. The first two apply to all radio equipment, and the third applies only to the categories a delegated regulation names. Article 3(1) covers health and safety, including the Low Voltage Directive’s safety objectives with no voltage limit applied, and electromagnetic compatibility. Article 3(2) requires equipment to use the radio spectrum efficiently and avoid harmful interference. Both apply to every piece of radio equipment placed on the European Union (EU) market, where compliance management for a radio product starts.

Article 3(3) is the conditional tier, and alongside the cybersecurity points it covers accessory and network interworking, interface connection and access to emergency services. The three cybersecurity points are protection of the network from harm and misuse, safeguards for personal data and privacy, and features protecting against fraud.

Which Products Are in Scope

A single connected device can carry one of the three cybersecurity obligations, or all three, depending on what it is and what it does:

• Network protection: Any radio equipment that can itself communicate over the internet is in scope, whether it communicates directly or through another device.
• Privacy safeguards: The requirement attaches only where the equipment can process personal, traffic or location data, and on that condition covers internet-connected equipment plus childcare, toy and wearable radio equipment, connected or not.
• Fraud protection: Internet-connected equipment that lets the holder or user transfer money, monetary value or virtual currency is in scope.

Mobile phones, smartwatches, baby monitors and industrial routers are in scope. A receive-only Digital Audio Broadcasting (DAB) radio isn’t, because it neither connects to the internet nor processes the data the privacy requirement turns on. Coverage follows connectivity and function rather than a manufacturer’s risk assessment, so two products off the same line can carry different obligations.

Where EN 18031 Restrictions Still Force a Notified Body

A Notified Body becomes unavoidable the moment a design trips one of the notices attached to the standard’s Official Journal citation. Each of the three parts carries a different set. EN 18031-1:2024 supports network protection, EN 18031-2:2024 privacy and EN 18031-3:2024 fraud, and all three were added to the harmonised standards list in January 2025.

Under all three parts, a device that lets the user skip setting a password loses presumption of conformity, because the Commission judged authentication risks not properly addressed when that option is allowed. For toy and childcare radio equipment falling under the access-control clauses of EN 18031-2, the standard supports self-declaration only where parental or guardian access control is in place. In EN 18031-3, the assessment criteria for secure updates do not provide presumption of conformity, because the Commission judges no single update method alone sufficient where money is involved.

Sections titled “Rationale” and “Guidance” provide information and carry no normative requirements. Treating them as normative is not applying the standard, and the presumption only ever covers the parts a manufacturer applied.

Article 17 of the RED sets out what follows. A manufacturer who has applied the harmonised standard can self-declare under internal production control (Module A). One who has applied it only in part must use EU-type examination (Module B) with conformity to type (Module C), or full quality assurance (Module H). Both routes put a third-party assessment body inside the process, and only for the essential requirements concerned.

What Trips an EN 18031 Assessment

Assessments come apart at the asset inventory, at the justification behind a “not applicable” verdict, and at firmware verification. EN 18031 evaluates each requirement through a cascading decision tree that ends in PASS, FAIL or NOT APPLICABLE, and EN 18031-1 alone defines eleven mechanism families, each with its own numbered requirements and its own tree. Teams should record a written rationale for every “Pass” or “Not applicable” path.

Identifying the assets is where the assessment starts, and a mis-scoped inventory carries through everything after it. Under-scoping it leaves requirements unaddressed, while over-scoping adds cost and delay. ACM-1, the first access control mechanism requirement, decides which of the authentication and later access control requirements apply at all, so a “not applicable” classification there needs strong justification.

The SUM-2 requirement exposes failures in firmware delivery and verification. Firmware delivered as an unsigned binary over Hypertext Transfer Protocol Secure (HTTPS) may fail the SUM-2 requirement in EN 18031-1 even when the device validates the Transport Layer Security (TLS) certificate. Because the payload itself carries no signature, the validated channel does not establish the integrity of the firmware. An undocumented verification chain fails the same way. The risk assessment behind those claims has to cover the product’s operational life and its end-of-life, not only the state it shipped in.

What Happens to RED Cybersecurity When the CRA Applies

The CRA already carries every one of the RED’s cybersecurity obligations, and the Commission has said it will repeal or amend the delegated regulation once the CRA applies to the same products, without naming a date. Until it does, RED market surveillance runs on, and the national bodies that already police radio equipment police its cybersecurity. Germany’s Bundesnetzagentur, France’s Agence Nationale des Fréquences and Finland’s Traficom are among them. A newer regime doesn’t launder non-compliance that predates it.

RED continues to govern efficient use of the radio spectrum, electromagnetic compatibility and electrical safety. The Article 3(3) requirements other than the three cybersecurity ones stay with it too, including network interworking and access to emergency services. Only that cybersecurity layer moves to the CRA, and the placing-on-market date decides which regime a given unit falls under, regardless of when it was designed or shipped. A RED exemption doesn’t carry over either. The CRA excludes medical devices, in vitro diagnostics and motor vehicles outright, aviation only where the product is certified under the EU aviation regulation, and electronic road toll systems not at all.

What the CRA Adds, and When

The CRA’s obligations don’t all arrive at once. Effective 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents within staged statutory deadlines. Full application on 11 December 2027 brings continuous vulnerability management. Manufacturers must also provide security updates across a support period of at least five years, or the expected use time where that is shorter. They must draw up a software bill of materials (SBOM) in a machine-readable format covering at least the product’s top-level dependencies.

Those reports go through a single reporting platform the European Union Agency for Cybersecurity (ENISA) runs, which passes each notification to the national response team acting as coordinator. prEN 40000-1-4, the draft generic security requirements standard for the CRA, builds on the EN 18031:2024 series and is targeted for publication in October 2027. No CRA harmonised standard had been cited in the Official Journal by September 2026, so the Article 27 presumption of conformity isn’t yet available to anyone.

Structuring the Technical File So It Survives the Handover

A traceable technical file links each Article 3(3) requirement to the EN 18031 clause that implements it, the design input requirement, the firmware that realizes it, and the verification and validation evidence that proves it. Under the RED the file covers the general description, the firmware versions that bear on compliance, design drawings, the harmonised standards applied in full or in part, test reports and a copy of the EU declaration of conformity. The CRA adds a cybersecurity risk assessment to that list. Manufacturers must keep the file and the declaration for ten years after the product is placed on the market.

Five linked artifacts sit on top of that file, and each one is where an assessment comes apart when it is missing or stale:

• Asset inventory: The documented security and network assets start every decision tree.
• Decision-tree records: Each mechanism gets one recorded path, PASS or NOT APPLICABLE, with written justification.
• Conceptual assessment documentation: The documentation holds the security design rationale, the objectives, and the threats and risks identified.
• Functional test records: Test cases map to assessment units, with results per mechanism.
• Vulnerability report: The initial vulnerability analysis feeds functional testing and practical exploitability.

Rotating a firmware signing credential or replacing the bootloader alters the SUM records, the asset inventory and the test evidence at once. A manually maintained requirements traceability matrix doesn’t report which of its decision-tree rationales went stale when it happened, so the matrix looks complete right up to the next conformity assessment.

How Jama Connect Supports RED Cybersecurity Compliance

The RED evidence structure maps onto the Traceability Information Model™ (TIM) in Jama Connect®, which defines the item types a project expects and the relationships it requires before any requirement is written. A TIM for an EN 18031 project can require every mechanism clause to trace to a derived requirement, every derived requirement to a test case, and every “not applicable” decision to a recorded rationale. Defining the asset inventory as its own item type lets under-scoping show up as requirements with no upstream asset, before conceptual assessment.

When a firmware update changes the verification chain, Live Traceability™ flags every SUM record and test run traced to it as suspect, across each degree of separation. The engineer then either updates the affected item or clears the flag. The cleared and updated flags are the decision trail the CRA’s lifecycle vulnerability obligations have to be evidenced against. Conceptual assessment rationale and the vulnerability report sit as linked items under the same model.

Carrying RED Evidence into the CRA Without Rebuilding It

Teams have to prepare CRA files while the standards bodies are still writing the harmonised standards those files will be judged against. prEN 40000-1-4 builds on the EN 18031 series, so a RED file that is still current when it publishes should carry much of the way forward, and October 2027 isn’t far off.

If your EN 18031 rationale records live in a spreadsheet nobody trusts after the last firmware release, establish a controlled transition baseline before CRA applicability. Jama Connect keeps that baseline and the decision trail behind it in one record, so you can start a free 30-day trial to capture one product’s approved RED file and compare every later change against it.

Frequently Asked Questions About the Radio Equipment Directive

Does the RED cybersecurity regime apply to wireless medical devices or connected vehicles?

Wireless medical devices are out entirely, connected vehicles only partly. Delegated Regulation (EU) 2022/30 removes all three requirements for equipment covered by the Medical Device Regulation or the In Vitro Diagnostic Regulation. Motor vehicles, civil aviation and electronic road toll systems lose only privacy and fraud, and still owe the Article 3(3)(d) network-protection requirement. Either way a medical-device team still owes cybersecurity evidence under EU MDR technical documentation, and Jama Connect supports the structured reviews and electronic approvals behind it.

Can ETSI EN 303 645 be used instead of EN 18031?

Not on its own. The European Telecommunications Standards Institute (ETSI) standard is voluntary, and the harmonised standards cited for the RED cybersecurity requirements are the three EN 18031 parts, so EN 303 645 confers no presumption of conformity. EN 18031-1 does carry an informative Annex C mapping its provisions to EN 303 645, which is the practical route to reusing work already done against it. Reusing that work means tracing each information security requirement to the EN 18031 clauses it satisfies.

Is IEC 62443 enough for industrial radio equipment sold in the EU?

No. International Electrotechnical Commission (IEC) 62443-4-1 and 62443-4-2 are not cited as harmonised standards under the RED, so they carry no presumption of conformity for the Article 3(3) requirements. EN 18031-1 publishes an informative Annex B mapping to EN IEC 62443-4-2. A manufacturer running an IEC 62443 program can use it to show which EN 18031 requirements that work already covers, and which still need evidence. Final responsibility for the file sits with the end-product manufacturer, whatever its component suppliers have certified.

This article was authored by Mario Maldari and published on September 14, 2026.