DEV Community: Vladimir Vician

RED Delegated Act & EN 18031 — What It Actually Requires in Hardware

Vladimir Vician — Fri, 06 Mar 2026 08:10:15 +0000

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.

We built a free CRA compliance scorer into a silicon advisor. Here's what we learned.

Vladimir Vician — Tue, 03 Mar 2026 04:45:00 +0000

A client came to us four months into PCB layout with a problem.

They'd chosen STM32F4. Solid MCU, team knew it, reasonable price. Then compliance
review hit: no hardware Secure Boot. No TrustZone. No hardware key storage.

Wi-Fi connected industrial gateway. EU market. CRA scope. Wrong chip — not a bad
chip, wrong chip for this use case.

Board spin: €40,000. Timeline impact: five months.

I've been in embedded hardware for over 10 years. That conversation happens more
than it should. So we built something to catch it earlier.

The regulatory context (skip if you know CRA)

EU Cyber Resilience Act enforcement: September 2026.

RED Delegated Act (Wi-Fi, BT, cellular products): August 2025 — already in effect.

Both have hardware implications that can't be patched in firmware:

Hardware Secure Boot (silicon-level, not software)
Hardware key storage (Secure Element or TrustZone — flash keys aren't compliant)
Per-device unique credentials (needs manufacturing provisioning infrastructure)
Anti-rollback protection (hardware monotonic counters)
Vulnerability disclosure policy before market entry

Most teams pick silicon based on cost and familiarity. Compliance gaps show up later,
when changing them is expensive.

What we built — and what we were honest about upfront

The MCU vs MPU Architecture Advisor
was built with a specific and limited scope: fast orientation, not a compliance report.

At the start of a project — before architecture locks, before BOM drafts — you
don't need 40 pages. You need a 30-second answer to: "Is this silicon direction
sane for EU market? What should I be worried about?"

That's what it does. Nothing more.

It won't replace a qualified embedded engineer or a formal CRA gap analysis.
But it asks the right questions at the moment it's cheapest to change the answer.

What it returns for a plain-English project description:

Dimension	Output
Architecture verdict	MCU / MPU / Crossover / FPGA + confidence %
Suggested silicon	Specific chips with 🇪🇺 EU origin flag
Supply chain risk	Non-EU silicon exposure warning
CRA risk	HIGH / MEDIUM / LOW + specific gaps
BOM complexity	Upstream dependency estimate
Engineering rationale	Shareable with your team

How CRA Article 13 maps to silicon

The hardest part of building this was translating regulatory language into
selection criteria:

CRA Requirement	What it means for silicon
Secure by default	Unused interfaces disabled at production
Cryptographic integrity	Hardware Root of Trust, full Secure Boot chain
Unique device identity	eFuse or Secure Element provisioning
Data at rest confidentiality	Hardware key storage — not flash
Lifetime update support	OTA with anti-rollback

Three projects — actual outputs

🌿 Laser weeding robot

Battery-powered, galvo control, 4G logging, IP65, EU Machinery Directive + GPSR

MCU — 91% confidence

Chip: STM32H7 (STMicroelectronics, 🇪🇺 Switzerland/Italy)

CRA: MEDIUM — Secure Boot capable, but provisioning infrastructure needed

Supply chain: 🟢 EU-origin

🎙 Edge AI mic array

7 mics, 360° beamforming, on-device wake word + speaker ID, BLE 5.3, EU RED + CRA

Crossover/MPU — 87% confidence

Chips: NXP i.MX RT1170 or i.MX 8M

CRA: HIGH — audio = personal data under EN 18031-2, full privacy architecture needed

Supply chain: ⚠ NXP Netherlands 🇪🇺, fab Taiwan

🚁 Drone AI compute

YOLOv8 on dual cameras at 30fps, no cloud, Wi-Fi 6, GPS log, CE + RED

FPGA — 78% confidence

Chips: AMD Xilinx Kria K26, Intel Agilex

CRA: HIGH — custom bitstream = non-standard update pathway, no EU-origin FPGA at this tier

Supply chain: 🔴 US-origin

What the results taught us

The FPGA recommendation surprises people most. Default assumption is MCU or MPU.

But 30fps inference on dual cameras with hard latency bounds — the parallelism
math wins.

EU silicon coverage is decent at MCU-class. STMicro (🇨🇭), Infineon (🇩🇪),
NXP (🇳🇱) cover most use cases. At FPGA performance tier, EU-origin doesn't
exist yet. That gap matters for programs with sovereignty requirements.

CRA risk is architecture-level, not just chip-level. A drone on custom FPGA
logic has fundamentally different vulnerability disclosure challenges than an MCU
on RTOS. The tool tries to flag that distinction.

Try it

Describe your project — the more specific the better. Power budget, interfaces,
OS requirements, EU regulatory scope. Vague input = generic output.

👉 inovasense.com/tools/mcu-vs-mpu

Free. No email. No sign-up.

One last thing: this is intentionally basic. The goal was never comprehensiveness —
it was speed. A 30-second check that catches the most common expensive mistakes
before they compound. If your project needs deeper analysis, that's what a
professional review is for. But most projects just need the right questions asked
early. That's what this does.

— Vladimir Vician, Founder @ Inovasense

10+ years in embedded hardware. We help EU manufacturers navigate CRA, RED, and CE marking.