RED Delegated Act 2025

Last Updated on 2025-10-27

From 1 August 2025, the EU flips the switch on the Radio Equipment Directive (RED) cybersecurity rules—the Delegated Regulation (EU) 2022/30 that activates Articles 3.3(d)(e)(f) for defined classes of radio equipment. If you ship cellular routers, DCUs, modems, gateways—or you buy them for AMI/SCADA—this is your first concrete cybersecurity “pass/fail” at the CE-marking gate, two years before CRA fully bites. EUR-Lex+1

This post breaks down the scope, the standards, the tricky bits (like default passwords), and how we’re aligning our WM Systems Industrial Router 2 / DCU line so utilities can sail through procurement without compliance heartburn.

What exactly is switching on?

The RED Delegated Act applies three cybersecurity essentials to certain radio equipment (i.e., devices with a radio interface such as LTE/NR, Wi-Fi, etc.):

• Article 3.3(d): the device must not harm the network or misuse resources (think DDoS, flooding, uncontrolled retries).
• Article 3.3(e): protect personal data and privacy (including traffic data or location data, after a 2023 correction).
• Article 3.3(f): protection from fraud (only when the device itself enables transferring money/monetary value). EUR-Lex+1
  

The regulation explicitly covers any radio equipment that can communicate over the internet by itself—directly or through another device. That squarely includes cellular routers, modems, and DCUs used in substations, cabinets, and meter rooms. For (e), it also covers gear that processes personal or traffic/location data—and network devices do process traffic data, so routers/DCUs fall in scope for (e) as well. EUR-Lex

Dates to know. The original application date (Aug 1, 2024) was postponed via Commission Delegated Regulation (EU) 2023/2444 to Aug 1, 2025—largely to give time for standards work. EUR-Lex

How do you prove compliance? Meet EN 18031 (with caveats)

The Commission published references to three harmonised standards that provide presumption of conformity—but with restrictions you need to read closely:

• EN 18031-1:2024 — common security and network security requirements for internet-connected radio equipment → maps to Article 3.3(d).
• EN 18031-2:2024 — security requirements for internet-connected, childcare, toy, and wearable radio equipment, etc that process data → maps to Article 3.3(e).
• EN 18031-3:2024 — security requirements for internet-connected radio equipment processing virtual money or monetary value → maps to Article 3.3(f).

These were listed in Implementing Decision (EU) 2025/138 with restrictions, notably: sections labelled “rationale” and “guidance” do not confer presumption; and if your implementation allows a user not to set/use any password, you lose presumption for the relevant clauses (and for money handling, certain “secure update” options alone are insufficient). In plain speak: don’t rely on advisory text; and don’t ship password-less or unchanged default credentials. EUR-Lex

Self-declaration vs Notified Body.

• If you fully apply the relevant harmonised standard(s) (respecting those restrictions), you can generally use Module A (internal production control) and self-declare.
• If you don’t (or only partly) apply harmonised standards, you must go via a Notified Body (Module B + C). The RED itself spells out that when standards are not (fully) applied, a NB route is required for Article 3.3 EUR-LexKiwa
  

What this means for cellular routers, modems and DCUs in utilities

1) “Don’t harm the network” ( Article 3.3(d) )

Routers and DCUs must be robust participants in public networks:

• Connection storm control: back-off/retry policies; watchdogs against endless attach loops.
• Traffic shaping & rate limiting for management interfaces and telemetry to prevent accidental floods.
• Service exposure minimisation: disable unneeded daemons; bind management to VPN/LAN only; drop legacy ciphers.
• Credential policy: no universal default logins; enforced initial unique credentials or equivalent secure onboarding.

Expect test evidence (or NB assessment) showing scenarios like SIM/network outages, APN misconfigurations, and malformed packets do not cause resource misuse. The EN 18031-1 control families map well to these needs. EUR-Lex

2) “Protect personal/traffic data and privacy” ( Article 3.3(e) )

Even if you don’t handle PII, routers process traffic data (metadata, IPs, session timing, GPS localization data) and sometimes location data from cellular modems. So:

• Encrypted management only (SSH, TLS, IPsec/OpenVPN/WireGuard) with modern suites.
• Access control & audit: RBAC, per-user accounts, immutable logs for auth/config changes.
• Data minimisation: avoid storing traffic/location data beyond operational necessity; provide log deletion and data export for audits.
• Secure defaults: force credential setup at first boot; randomised device secrets; no open services.

The 2023 amendment clarified that processing traffic data or location data suffices to bring (e) into scope—important for network gear. EUR-Lex

3) “Protection from fraud” ( Article 3.3(f) )

Most utility routers/DCUs don’t process payments; if yours doesn’t enable transferring money/monetary value, (f) is not applicable. If you integrate prepayment mechanisms or vending flows, you’ll need EN 18031-3 controls, including stricter update and authentication guarantees. EUR-Lex

The tricky parts auditors will actually poke

• Default passwords: If your product allows operating without a password or lets the user skip setting one, you lose presumption of conformity under EN 18031-1/-2/-3. Enforce initial credential creation (or certificate-based bootstrap) in the out-of-box flow. EUR-Lex
  
• “Guidance” ≠ compliance: Anything labelled rationale/guidance in EN 18031 doesn’t count for presumption. Your test matrices must point to normative EUR-Lex
  
• Partial application: If you cherry-pick controls or deviate, be ready for a Notified Body evaluation and a risk-based justification tied back to Article 3.3. SGSCorp
  

How we’re aligning WM Systems gear for RED 2025

Our Industrial Router 2 and DCU platform were already redesigned for demanding utility buyers (see the ENCS-grade security we’ve talked IN ANOTHER POST). For the RED Delegated Act, we’ve focused on making compliance demonstrable—not just “secure in spirit.”

(The 450MHz Alliance organization has posted a news on its website about our new secure router – which was examined by ENCS according to strict security requirements. )

Design & hardening

• Secure boot chain + signed firmware with A/B atomic updates and rollback; update packages verifiable offline for locked-down sites.
• Service minimisation profile by SKU (router/DCU/logger): only required daemons enabled; management bindable to VPN-only.
• Credential bootstrap: first-boot unique admin setup or mutual-TLS enrollment; no default accounts to log in with.
• Rate limiting & back-off across PPP/IP and management endpoints to mitigate resource abuse.

Privacy/traffic data controls

• RBAC with per-user audit logs (config changes, firmware actions, login attempts).
• Encrypted management everywhere (SSH/TLS/IPsec/OpenVPN/WireGuard); no plaintext
• Data retention knobs for logs/diagnostics; one-click purge for field returns to avoid leaking traffic/location metadata.

Test & evidence

• EN 18031 mapping: our test plans cite normative clauses only, sidestepping the OJ “guidance” limitation.
• “No-password” ban enforced in the UI/CLI; failing that control is a blocker.
• DoC templates prepared for Module A, with a Notified Body fall-back path if a customer’s profile needs it (e.g., prepayment integration). EUR-Lex+1
  

Buyer’s mini-checklist for RFPs and FAT/SAT (RED edition)

Ask vendors to provide, before you sign:

1. Scope mapping: A one-pager confirming Articles 3.3(d) and (e) in scope for the device (routers/DCUs: yes), and (f) only if payments are enabled. Quote the device’s radio interfaces and whether it processes traffic/location data. EUR-Lex
   
2. Standards route: State whether they apply EN 18031-1/-2 fully (with OJ restrictions acknowledged) for self-declaration, or whether they will use a Notified Body. Include the test plan cross-reference. EUR-Lex+1
   
3. Default-credential proof: Evidence that first boot forces credentials/certs; screenshots or a short video from the released firmware. EUR-Lex
   
4. Network protection tests: Results demonstrating throttling/back-off, service exposure minimisation, and failure-mode behaviour on network loss. (This goes to 3(3)(d).) EUR-Lex
   
5. Privacy controls: RBAC, audit logs, encryption, log-retention settings, and secure data wipe procedures for RMA. (This goes to 3(3)(e).) EUR-Lex
   

RED vs CRA: how they fit together

Think of RED 2025 as your device-level cyber baseline for radio gear, enforced at market entry for specific classes, while the Cyber Resilience Act (CRA) (full application Dec 11, 2027) imposes horizontal, lifecycle obligations (e.g., vulnerability handling and multi-year security support) across all products with digital elements. For many utilities, RED is now, CRA is next—and the good news is the controls you implement for RED (secure defaults, update integrity, access control) are the same muscles you’ll need for CRA. EUR-Lex

Practical next steps (OEMs & utilities)

For OEMs/integrators

• Decide your route: aim for EN 18031 full application (Module A) or plan a Notified Body engagement (Module B+C).
• Fix the foot-guns: remove universal defaults; enforce initial credential setup; lock management to secure channels.
• Harden and document: produce a test matrix citing only normative clauses; create a DoC template; prepare FAT/SAT scripts that mirror EN 18031 controls. EUR-Lex
  

For utilities/DSOs

• Update tenders now so shipments after 1 Aug 2025 aren’t delayed at customs. Require an EN 18031 mapping or NB certificate, plus proof that no-password operation is impossible.
• Pilot firmware early: verify that credential bootstrap and service exposure match your security policies and that logs are adequate for incident response. EUR-Lex
  

Where WM Systems can help

Because our portfolio is built for mission-critical AMI/SCADA, we’re treating RED as an opportunity to make security auditable:

• RED 2025 readiness pack: EN 18031 mapping, normative-clause test matrix, DoC sample, and FAT/SAT scripts aligned to Articles 3.3(d) and (e).
• Industrial Router 2 / DCU firmware with enforced first-boot credential setup, signed A/B updates with rollback, RBAC + audit logs, and hardened service profiles—ready for Module A self-declaration, with NB path available where needed. EUR-Lex
  

If you’re planning rollouts straddling 2025–2027, we can align your device selection and acceptance tests to RED now and CRA later, so you don’t redo work or stall at CE.

Sources & official texts

• Delegated Regulation (EU) 2022/30 (radio-equipment cybersecurity scope: who’s in, and what requirements apply). EUR-Lex
  
• Delegated Regulation (EU) 2023/2444 (postpones application to 1 Aug 2025; corrects traffic OR location data). EUR-Lex
  
• Implementing Decision (EU) 2025/138 (lists EN 18031-1/-2/-3:2024 with restrictions; default-password warning; guidance/rationale not conferring presumption). EUR-Lex
  
• Commission RED overview page (scope and purpose of Article 3(3) additions). Internal Market & Industry
  
• Notified-Body/self-declaration guidance for RED 3(3) essentials. EUR-LexKiwaSGSCorp