What is the RED Delegated Act?
The RED Delegated Act (Commission Delegated Regulation EU 2022/30) activates Articles 3.3(d), (e), and (f) of the Radio Equipment Directive (2014/53/EU), making cybersecurity, privacy, and fraud protection mandatory for all internet-connected radio equipment sold in the EU from August 1, 2025. The harmonized standard series EN 18031-1/2/3 defines the specific technical requirements. Non-compliance means products cannot legally bear the CE mark for radio equipment.
The Regulatory Context: What Changed
The Radio Equipment Directive (RED) has contained Articles 3.3(d), (e), and (f) since 2014. These articles define protection requirements for networks, personal data, and fraud prevention. For ten years, they were optional — manufacturers could invoke them, but were not required to.
The RED Delegated Act (EU 2022/30) changes that. From August 1, 2025, these requirements are mandatory for all radio equipment that can connect to the internet — directly or through a gateway.
The date was delayed once already: the original deadline was August 2024, postponed to allow time for the harmonized standard EN 18031 to be finalized and published (which occurred in early 2025). There will be no further extensions.
Relationship to CE marking: The CE marking framework now includes EN 18031 as a required harmonized standard for internet-connected radio equipment. Updating the Declaration of Conformity without EN 18031 test evidence will result in an incomplete Technical File.
Who Is Affected
If your product has any wireless interface and can — directly or through a connected device — reach the internet, it is in scope:
| Device Type | In Scope? |
|---|---|
| Wi-Fi-enabled devices (all categories) | ✅ Yes |
| Bluetooth devices that relay through a smartphone or hub | ✅ Yes |
| Cellular IoT (LTE-M, NB-IoT, Cat-1) | ✅ Yes |
| Smart home sensors, gateways, hubs | ✅ Yes |
| Wearables (smartwatches, fitness trackers, health monitors) | ✅ Yes |
| Baby monitors, childcare cameras | ✅ Yes |
| Wireless payment terminals | ✅ Yes (also EN 18031-3) |
| Zigbee/Z-Wave devices connected to an internet gateway | ✅ Yes |
| Standalone Bluetooth device with no data path to internet | Grey area — seek legal opinion |
Important: The scope is “internet-connected radio equipment” — not just consumer products. Industrial IoT, connected medical accessories (not MDR-classified), smart building sensors, and logistics trackers are all in scope if they have a wireless interface with an internet data path.
What EN 18031 Actually Requires
The harmonized standard series EN 18031 consists of three parts, each mapping to one article of the Delegated Act:
EN 18031-1 — Network Protection (Art. 3.3(d))
The device must not harm the network or misuse network resources. In hardware terms:
- Network protection — The device must not actively harm the network. Services must not be exposed by default (no open telnet, unprotected MQTT, or open debug ports). Implementing exponential backoff and rate limiting for reconnection is strongly recommended to demonstrate compliance.
- Software integrity [SUM-2] — EN 18031-1 requires that the device only installs software whose integrity and authenticity are valid at the time of installation. The standard is technology-neutral: accepted implementations include digital signatures verified in the bootloader, secure-channel-only delivery from an authenticated source, or access-control combined with hash. Hardware Secure Boot (ROM-resident, silicon-level verification) is the strongest implementation and is strongly recommended for elevated threat models or devices also subject to EN 18031-3 (fraud prevention). However, it is not explicitly mandated by EN 18031-1 — software-based verification with thorough documentation in the Technical File can satisfy SUM-2.
Technical File implication: If you implement SUM-2 via digital signatures, the signing key management and bootloader verification logic must be thoroughly documented. Weak or undocumented verification chains are the most common cause of SUM-2 assessment failure.
EN 18031-2 — Privacy Protection (Art. 3.3(e))
The device must protect personal data and user privacy. Applicable to all devices that process, store, or transmit personal, traffic, or location data.
- Hardware key storage (or equivalent SSM) — EN 18031 is technology-neutral: it mandates a Secure Storage Mechanism (SSM) for cryptographic keys, not a specific implementation. Accepted approaches include ARM TrustZone with a key management service, an external Secure Element (e.g., ATECC608B, STSAFE-A, SE050), or an MCU with OTP/eFuse-based key storage. Software-based SSM implementations without hardware isolation are possible but require extensive justification in the Technical File — most test labs will scrutinise these closely.
- No universal default passwords — Devices must not ship with shared factory credentials. Each unit needs a unique password, or the device must force a password change on first use with hardware-enforced provisioning.
- Data minimization architecture — The device should not collect or transmit data beyond what is necessary. This is primarily a software/firmware design requirement, but hardware choices (e.g., including a microphone when not needed) are relevant.
- Children’s devices specifically — EN 18031-2 includes specific requirements for devices intended for children: parental control interfaces, restricted data collection, and stricter access control.
Hardware implication: An ESP32 storing Wi-Fi credentials and device keys in NVS flash (unencrypted, with no software-layer protection) does not meet SSM requirements. Whether hardware or software-based key protection is used, plaintext keys accessible from the application context = non-compliant.
EN 18031-3 — Fraud Prevention (Art. 3.3(f))
Applies to devices that handle financial transactions, monetary value, or virtual currency:
- Hardware-rooted firmware verification — For payment devices, the firmware verification chain must be hardware-rooted (Secure Boot). A digital signature alone, without a hardware root of trust anchoring the verification, is generally considered insufficient for this threat model — the entire verification chain becomes compromised if the verifier itself can be replaced.
- Secure payment interfaces — Interfaces handling payment credentials must be isolated at the hardware level.
- Transaction verification mechanisms — Devices must implement safeguards against replayed or injected transaction commands.
Who this affects: Connected point-of-sale terminals, e-wallet wearables, mobile payment accessories, cryptocurrency hardware wallets, smart meters with prepayment functionality.
Hardware Decisions You Cannot Patch
This is the section most teams miss. Several EN 18031 requirements trace directly to silicon-level architecture decisions that cannot be retrofitted in firmware:
| Requirement | Hardware Decision | MCUs That Support It |
|---|---|---|
| Hardware Secure Boot | ROM bootloader + eFuse/OTP key storage | STM32U5, nRF5340, ESP32-S3, i.MX RT1170, STM32H5 |
| Hardware key isolation | TrustZone or Secure Element | ARM Cortex-M33+, ATECC608B, SE050, STSAFE-A |
| Rollback protection (best practice, not normative — EN 18031-1 Clause 6.3.3 Guidance) | Hardware monotonic counter (OTP/eFuse) or secure version counter | nRF9160, STM32H5, ESP32-S3, STM32WBA |
| Per-device unique credentials | Manufacturing provisioning infrastructure | Requires eFuse burning or SE provisioning at production |
| TRNG for key generation | On-chip true random number generator | Most modern MCUs — verify in datasheet |
Legacy warning: STM32F4, STM32F7, and similar older Cortex-M4/M7 parts without TrustZone have limited Secure Boot support. Designs based on these chips may require a board revision to comply — not a firmware update. If you are designing on these platforms, we recommend an architecture review before committing to manufacturing.
The National Enforcement Reality
The Delegated Act is EU law, enforced nationally. Enforcement is not uniform across member states, and the level of market surveillance activity varies:
🇩🇪 Germany — Bundesnetzagentur (BNetzA) Germany historically has some of the most active product market surveillance in the EU. The BNetzA purchases and tests products independently, runs targeted campaigns, and actively removes non-compliant products. Products sold on Amazon.de and through German distributors should assume scrutiny.
🇫🇷 France — DGCCRF + Customs (DGDDI) The DGCCRF (Directorate-General for Competition, Consumer Affairs and Fraud) covers product compliance. French customs actively screens imports for compliance documentation and can detain shipments pending documentation review.
🇳🇱 Netherlands — RDI (Radiocommunications Agency Netherlands) The RDI is an active participant in EU-wide ADCO RED joint campaigns. The Netherlands is a major port of entry for EU market goods — RDI has leverage at customs inspection points.
🇸🇪 Sweden — PTS (Post and Telecom Authority) Known for proactive enforcement on IoT and connected consumer devices. Active in pan-EU surveillance campaigns.
Practical consequence: Non-compliance discovered by any national authority results in market withdrawal and notification to the Safety Gate / RAPEX system. Once a product is notified, other member states are automatically alerted. A compliance failure in Germany is effectively an EU-wide compliance failure.
The CRA Relationship
The RED Delegated Act and the Cyber Resilience Act (CRA) (EU 2024/2847) overlap in scope for connected hardware:
| Aspect | RED Delegated Act | CRA |
|---|---|---|
| Applies from | August 1, 2025 | December 11, 2027 |
| Scope | Internet-connected radio equipment | All products with digital elements |
| Standard | EN 18031-1/2/3 | EN 18031 + IEC 62443 + new CRA standards |
| SBOM required | No | Yes |
| Vulnerability reporting | No | Yes (24h to ENISA from Sep 2026) |
| Relationship | CRA will supersede RED cybersec requirements | Broader; absorbs RED Delegated Act scope |
Practical implication: EN 18031 compliance today gives you the security hardware foundation for CRA readiness in 2027. It does not cover SBOM, vulnerability management, or lifecycle obligations — those are CRA-specific additions. See our CRA hardware compliance checklist for the full CRA requirements.
The Pre-August Checklist
For any internet-connected radio product currently on the EU market or in active development:
Scope:
- Confirm the product has an internet data path (direct or via gateway)
- Identify which EN 18031 parts apply (18031-1 always; -2 if personal data; -3 if payments)
Hardware:
- Secure Boot: hardware-enforced chain confirmed and implemented
- Key storage SSM: TrustZone + key service, Secure Element, OTP/eFuse, or software-based with documented risk justification in Technical File
- Anti-rollback: hardware monotonic counter present and integrated
- Default password: unique per-device or first-use forced change confirmed
- TRNG: hardware random number generator in silicon or external
Documentation:
- Technical File updated with EN 18031-x test evidence
- Declaration of Conformity updated to reference Articles 3.3(d)(e)(f)
- EN 18031 conformity assessment path confirmed — self-declaration (Module A) is permitted for most devices; specific product characteristics (password bypass mechanisms, children’s devices, payment functionality) may trigger a notified body requirement. Verify against the applicable clauses for your specific product.
If any hardware items are gaps today, you have a board respin decision to make. The manufacturing lead time and re-testing timeline make August 2025 very close.
About the Author
Vladimir Vician is the founder of Inovasense, an EU-based embedded hardware and compliance engineering company. With over 10 years of experience in embedded hardware design, he works with hardware manufacturers on complete EU regulatory compliance — from silicon selection and Technical File preparation to CE marking and CRA readiness. He is the author of the MCU vs MPU Architecture Advisor tool used by hardware teams across Europe.
Connect on LinkedIn · Inovasense Embedded Security & IoT
Official References
- Commission Delegated Regulation (EU) 2022/30 — RED Delegated Act full text — EUR-Lex
- Directive 2014/53/EU (RED) — Base directive — EUR-Lex
- European Commission — Radio Equipment Directive page (Articles 3.3(d)(e)(f) section) — European Commission
- European Commission press release — Commission strengthens cybersecurity of wireless devices (Oct 2021) — European Commission
- ADCO RED — Administrative Cooperation Group for RED — European Commission