Originally published at inovasense.com
We had a client with a RED-certified Wi-Fi product. Certificate from a notified body. Clean Declaration of Conformity. August 2025 deadline circled on the calendar.
Then we asked: "Have you tested to EN 18031?"
Silence.
"We have the RED certificate," they said.
"That covers Articles 3.1 and 3.2," I said. "The Delegated Act activates Article 3.3. That's different tests. And it's mandatory from August 1st."
They had 14 weeks to fix it. Tight — but they made it.
Most teams in 2025 still don't know this is coming.
The Regulatory Context: What Changed
The Radio Equipment Directive (RED) has contained Articles 3.3(d), (e), and (f) since 2014. For ten years, they were optional. The RED Delegated Act (EU 2022/30) makes them mandatory from August 1, 2025 for all internet-connected radio equipment.
The date was delayed once from August 2024 — to allow EN 18031 to be finalized and published (early 2025). There will be no further extensions.
Who Is Affected
If your product has any wireless interface and can reach the internet — directly or through a gateway — it's in scope:
| Device Type | In Scope? |
|---|---|
| Wi-Fi-enabled devices | ✅ Yes |
| Bluetooth IoT (via hub/phone) | ✅ Yes |
| Cellular IoT (LTE-M, NB-IoT) | ✅ Yes |
| Smart home sensors/gateways | ✅ Yes |
| Wearables, baby monitors | ✅ Yes |
| Wireless payment terminals | ✅ Yes (also EN 18031-3) |
| Zigbee/Z-Wave via internet gateway | ✅ Yes |
| Pure BT with no internet data path | Grey area |
Industrial IoT, 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 in Hardware
EN 18031-1 — Network Protection (Art. 3.3(d))
Hardware implication: If your MCU doesn't support silicon-level hardware Secure Boot, you cannot satisfy this in firmware. This is a silicon selection decision.
- Hardware Secure Boot — ROM-resident bootloader verifies cryptographic signature before executing any code from flash. Not configurable in software.
- No open network interfaces by default — Open telnet, unprotected MQTT endpoints fail this.
- Rate-limited reconnection logic — retry storms = non-compliant.
EN 18031-2 — Privacy Protection (Art. 3.3(e))
Hardware implication: An ESP32 storing Wi-Fi credentials in NVS flash (unencrypted, with no software-layer protection) does not meet SSM requirements. Plaintext keys accessible from the application context = non-compliant.
- Key storage SSM — EN 18031 is technology-neutral: it mandates a Secure Storage Mechanism (SSM), not a specific implementation. Accepted: TrustZone + key service, Secure Element (ATECC608B, STSAFE-A, SE050), or OTP/eFuse-based storage. Software-based SSM possible but requires extensive justification in the Technical File.
- No universal default passwords — Unique per-device or forced change on first use.
- Children's devices — stricter data minimization and access control requirements.
EN 18031-3 — Fraud Prevention (Art. 3.3(f))
Applies if your device handles financial transactions or monetary value.
- The standard explicitly states that a digital signature alone is often insufficient — the verification chain must be hardware-rooted.
- Hardware-isolated payment interfaces and anti-replay protection required.
The Silicon Decisions You Cannot Patch
| Requirement | Hardware Decision | MCUs That Support It |
|---|---|---|
| Hardware Secure Boot | ROM bootloader + eFuse/OTP | STM32U5, nRF5340, ESP32-S3, i.MX RT1170, STM32H5 |
| Key storage SSM | TrustZone, Secure Element, OTP/eFuse, or software-based with Technical File justification | ARM Cortex-M33+, ATECC608B, SE050, STSAFE-A |
| Anti-rollback | Hardware-enforced version tracking (OTP/eFuse or secure version counter) | nRF9160, STM32H5, ESP32-S3, STM32WBA |
| Per-device credentials | Manufacturing provisioning | eFuse burning or SE provisioning at production |
Legacy warning: STM32F4, STM32F7 (Cortex-M4/M7, no TrustZone) have limited Secure Boot support. Designs on these chips may require board revision — not firmware update.
National Enforcement Reality
- 🇩🇪 Germany (BNetzA) — Most active EU market surveillance. Purchases products and tests them independently. No complaint required.
- 🇫🇷 France (DGCCRF + customs) — Screens imports, can detain shipments pending documentation.
- 🇳🇱 Netherlands (RDI) — Major port of entry, active in ADCO RED joint campaigns.
- 🇸🇪 Sweden (PTS) — Proactive on IoT and consumer devices.
Non-compliance found anywhere = Safety Gate notification = EU-wide market withdrawal.
RED Delegated Act vs CRA
| Aspect | RED Delegated Act | CRA |
|---|---|---|
| Applies from | August 1, 2025 | December 11, 2027 |
| Scope | Internet-connected radio equipment | All products with digital elements |
| SBOM required | No | Yes |
| Vulnerability reporting | No | Yes (24h to ENISA from Sep 2026) |
EN 18031 compliance = hardware security foundation for CRA readiness in 2027. But CRA adds SBOM, vulnerability management, and lifecycle obligations on top.
Pre-August Checklist
Hardware:
- [ ] Secure Boot: hardware-enforced chain implemented
- [ ] Key storage SSM: TrustZone + key service, Secure Element, OTP/eFuse, or software-based with documented risk justification in Technical File
- [ ] Anti-rollback: hardware-enforced version tracking confirmed
- [ ] Default password: unique per-device or first-use forced change
- [ ] TRNG: hardware random number generator confirmed
Documentation:
- [ ] Technical File updated with EN 18031-x test evidence
- [ ] Declaration of Conformity references Articles 3.3(d)(e)(f)
- [ ] EN 18031 conformity assessment completed (verify if specific clauses trigger notified body requirement)
If hardware gaps exist today — you have a board respin decision. Manufacturing lead times make August 2025 very close.
Vladimir Vician — Founder @ Inovasense
10+ years embedded hardware. We help EU manufacturers navigate CRA, RED and CE marking — from silicon selection to Technical File.
Top comments (0)