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:
- No uncontrolled retry storms or connection flooding — Your firmware’s reconnection logic must implement backoff and rate limiting. This is a software requirement, but it must be testable.
- Secure Boot — The device must not be capable of running unauthorized firmware that could be weaponized to attack network infrastructure. This requires a hardware-enforced boot chain: ROM-resident bootloader that verifies cryptographic signature before executing any code from flash. See our Secure Boot glossary entry for implementation detail.
- Access control to network interfaces — Services must not be exposed by default. An open telnet or unprotected MQTT endpoint that accepts commands over the network fails this requirement.
Hardware implication: If your MCU does not support hardware Secure Boot (silicon-level, cryptographic verification from immutable ROM), you cannot satisfy this requirement in firmware. This is a silicon selection decision.
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 — Encryption keys protecting personal data must not be stored in plaintext in application flash. Acceptable implementations: 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.
- 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) does not meet this requirement for data classified as personal. The PSRAM/flash encryption feature must be enabled — which requires eFuse burning in the manufacturing process.
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 — The standard explicitly notes that a digital signature alone is often insufficient. The signature verification chain must be hardware-rooted (Secure Boot) to prevent a compromised update pathway from being used for payment fraud.
- 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 |
| Anti-rollback protection | Hardware monotonic 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
- Hardware key storage: TrustZone + key service, or Secure Element in BOM
- 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 completed (self-declaration is permitted for most devices)
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