Safeguard
Compliance•

EN 18031 and the RED Cybersecurity Rules: What Applies Until December 2027, and What Comes After

Which wireless products fall under the EU Radio Equipment Directive cybersecurity rules, how EN 18031 and its restricted citation work, and how the 2026 repeal hands them to the Cyber Resilience Act on 11 December 2027.

Safeguard Security Team
9 min read

If you sell wireless products that connect to the internet in the EU, cybersecurity has been a legal condition of market access since 1 August 2025. The rules come from a 2022 delegated regulation under the Radio Equipment Directive (RED), and the harmonised standard most manufacturers use to meet them is EN 18031. In February 2026 the Commission repealed that regulation, with effect from 11 December 2027, the day the Cyber Resilience Act (CRA) applies in full.

This explainer is for product, engineering and compliance leads at companies that ship Wi-Fi, Bluetooth, cellular or other radio products. It covers which products are in scope, what EN 18031 covers and where its citation is restricted, and how the handover to the CRA works. It describes the legal texts, not legal advice for your specific product.

The short answer

Commission Delegated Regulation (EU) 2022/30 makes three RED essential requirements apply to certain radio equipment from 1 August 2025: Article 3(3)(d) on not harming networks, 3(3)(e) on protecting personal data and privacy, and 3(3)(f) on protection from fraud. The harmonised standards are EN 18031-1, -2 and -3, cited in the Official Journal on 30 January 2025 with restrictions. Delegated Regulation (EU) 2026/339 repeals 2022/30 from 11 December 2027, when the CRA's own requirements take over. Equipment placed on the market between 1 August 2025 and 10 December 2027 remains subject to RED market surveillance for those requirements.

Which products are in scope

The regulation attaches each requirement to a different group of radio equipment. "Radio equipment" means products that intentionally emit or receive radio waves, which covers most Wi-Fi, Bluetooth, cellular, Zigbee, LoRa and NFC products.

RED requirementApplies toHarmonised standard
Art. 3(3)(d): does not harm the network or misuse network resourcesRadio equipment that can communicate over the internet, directly or via other equipmentEN 18031-1
Art. 3(3)(e): safeguards for personal data and privacyInternet-connected radio equipment, childcare equipment, toys and wearables, if they process personal, traffic or location dataEN 18031-2
Art. 3(3)(f): features protecting from fraudInternet-connected radio equipment that lets the user transfer money, monetary value or virtual currencyEN 18031-3

Two details are easy to miss. First, "internet-connected" includes devices that reach the internet through something else, such as a Bluetooth sensor that syncs through a phone app. Second, the privacy requirement reaches some products that are not internet-connected at all: a Bluetooth children's smartwatch that processes location data is in scope for 3(3)(e) on its own.

There are carve-outs. Equipment covered by the Medical Devices Regulation (EU) 2017/745 or the In Vitro Diagnostics Regulation (EU) 2017/746 is exempt from all three requirements. Equipment covered by the EU aviation rules (Regulation (EU) 2018/1139), vehicle type-approval (Regulation (EU) 2019/2144) or electronic road tolling (Directive (EU) 2019/520) is exempt from (e) and (f), but not from (d).

A first-pass scoping helper

This script encodes the scope rules above so you can run your product line through them quickly. It is a triage aid for deciding where to spend legal and test-lab time, not a conformity decision.

#!/usr/bin/env python3
"""First-pass scoping of the RED cybersecurity rules (Delegated Regulation (EU) 2022/30).
Edit the DEVICE dict and run: python3 red_scope.py. Not legal advice."""
from datetime import date

DEVICE = {
    "name": "Smart doorbell",
    "radio": True,                 # intentionally emits or receives radio waves
    "internet_connected": True,    # can communicate over the internet, directly or via other equipment
    "processes_personal_data": True,  # personal, traffic or location data
    "childcare": False, "toy": False, "wearable": False,
    "moves_money": False,          # transfers money, monetary value or virtual currency
    "other_law": None,             # "MDR", "IVDR", "aviation", "vehicle", "road-tolls" or None
    "placed_on_market": date(2026, 11, 1),
}

def scope(d):
    if not d["radio"]:
        return ["Not radio equipment: the RED rules do not apply (the CRA may still apply from 11 Dec 2027)."]
    if d["placed_on_market"] >= date(2027, 12, 11):
        return ["Placed on the market from 11 Dec 2027: Delegated Regulation 2022/30 is repealed; assess under the CRA instead."]
    if d["placed_on_market"] < date(2025, 8, 1):
        return ["Placed on the market before 1 Aug 2025: the 2022/30 requirements did not yet apply."]
    reqs = []
    if d["internet_connected"]:
        reqs.append(("3(3)(d) network protection", "EN 18031-1"))
    if d["processes_personal_data"] and (d["internet_connected"] or d["childcare"] or d["toy"] or d["wearable"]):
        reqs.append(("3(3)(e) personal data and privacy", "EN 18031-2"))
    if d["internet_connected"] and d["moves_money"]:
        reqs.append(("3(3)(f) protection from fraud", "EN 18031-3"))
    if d["other_law"] in ("MDR", "IVDR"):
        reqs = []
    elif d["other_law"] in ("aviation", "vehicle", "road-tolls"):
        reqs = [r for r in reqs if r[0].startswith("3(3)(d)")]
    if not reqs:
        return ["None of RED Art. 3(3)(d), (e) or (f) applies under 2022/30."]
    return [f"Art. {art} applies; harmonised standard: {std}" for art, std in reqs]

print(DEVICE["name"])
for line in scope(DEVICE):
    print(" -", line)
$ python3 red_scope.py
Smart doorbell
 - Art. 3(3)(d) network protection applies; harmonised standard: EN 18031-1
 - Art. 3(3)(e) personal data and privacy applies; harmonised standard: EN 18031-2

Change the profile and run it again. A Bluetooth-only children's smartwatch that processes location data returns only 3(3)(e). A connected payment terminal returns all three. A device covered by the MDR returns none. A product first placed on the market after 11 December 2027 is pointed at the CRA instead.

What EN 18031 asks for, and where the citation is restricted

EN 18031 is published in three parts, one per requirement. Each part sets security requirements and assessment criteria for the product, and asks the manufacturer to document which requirements apply and how the design meets them.

Applying a harmonised standard whose reference is in the Official Journal gives a presumption of conformity, which lets most manufacturers self-assess. But Implementing Decision (EU) 2025/138, which added EN 18031 to the list, attached notices that limit that presumption:

  • Rationale and guidance text doesn't count. In all three parts, the sections named "rationale" and "guidance" do not confer a presumption of conformity. Only the requirements do.
  • Optional passwords break the presumption. In all three parts, if applying clauses 6.2.5.1 and 6.2.5.2 means the user is allowed not to set and use any password, the standard does not confer a presumption of conformity. A product that ships with "skip password setup" falls outside the standard's safe harbour.
  • Parental controls for children's products (Part 2). For the classes of equipment covered by clauses 6.1.3 to 6.1.6, there is no presumption unless parental or guardian access control is ensured.
  • Fraud assessment criteria (Part 3). The assessment criteria in clause 6.3.2.4 do not confer a presumption of conformity for the fraud requirement.

Why this matters: under Article 17 of the RED, a manufacturer that applies the cited harmonised standards can use internal production control (self-assessment). One that has not applied them, or has applied them only in part, must go through EU-type examination or full quality assurance, both of which involve a notified body. A design choice like optional passwords can therefore change your conformity route, your timeline and your cost.

The handover to the CRA

The CRA covers products with digital elements far more broadly than the RED rules do, and its essential cybersecurity requirements include everything in RED Article 3(3)(d), (e) and (f). Recital 30 of the CRA says so directly. To avoid radio equipment being subject to two overlapping regimes, the Commission adopted Delegated Regulation (EU) 2026/339 on 16 February 2026. It was published in the Official Journal on 29 April 2026 and entered into force on 19 May 2026. Its operative text is one sentence: Regulation 2022/30 "is repealed with effect from 11 December 2027".

The repeal does not wipe the slate. Its recital 5 states that market surveillance under the RED continues for radio equipment placed on the market between 1 August 2025 and 10 December 2027. A device you ship in 2026 can still be checked against the RED cybersecurity requirements years from now.

In practice, products fall into three groups:

Placed on the EU marketCybersecurity rules
Before 1 August 2025RED 3(3)(d), (e), (f) did not apply under 2022/30
1 August 2025 to 10 December 2027RED 3(3)(d), (e), (f) as scoped above; market surveillance continues after the repeal
From 11 December 2027CRA essential requirements (products with digital elements); 2022/30 no longer applies

The CRA's vulnerability reporting duties already apply, since 11 September 2026, to products with digital elements on the market, including radio products. We covered those in CRA Article 14 reporting, and the status of the CRA's own standards in CRA harmonised standards.

What to do now

  1. Inventory your radio products by placement date. Anything placed on the market since 1 August 2025 needs RED cybersecurity evidence on file, even if your next generation will be assessed under the CRA.
  2. Check your EN 18031 file against the restrictions. If a product lets users skip a password, or is a children's product without parental controls, you may not have the presumption of conformity you think you have.
  3. Reuse the work for the CRA. The CRA's essential requirements include everything RED 3(3)(d), (e) and (f) cover, so the security decisions you document for EN 18031 are a starting point for CRA Annex I. Build one evidence set that serves both, rather than two parallel projects.
  4. Plan the December 2027 cutover. Products you will still be shipping after 11 December 2027 need CRA conformity by then, including CRA-specific obligations the RED rules never had, such as vulnerability handling for the support period and an SBOM.

Is this worth acting on with the repeal coming?

It is tempting to wait it out. The RED rules end in December 2027 and the CRA will replace them, so why invest in EN 18031 now? The answer is in recital 5 of the repeal: anything you place on the market before the cutover stays answerable under the RED rules. The repeal shortens the regime's life for new products. It does not create an amnesty for products already shipped.

The better framing is that EN 18031 work is a down payment on the CRA. The CRA's requirements include everything the RED rules ask for, so a team that has already documented its radio products' security decisions has a head start on the evidence the CRA will expect.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.