EN 18031 — Cybersecurity Standard for Radio Equipment under RED
EN 18031 is a three-part European harmonised standard series developed by ETSI and CEN/CENELEC to operationalise the cybersecurity requirements introduced by the RED Delegated Act (Commission Delegated Regulation EU 2022/30). The standard series provides the specific technical requirements manufacturers must meet to demonstrate conformity with Articles 3(3)(d), (e), and (f) of the Radio Equipment Directive — the three clauses activated by the Delegated Act.
Key Facts
| Detail | Information |
|---|---|
| Standard series | EN 18031-1, EN 18031-2, EN 18031-3 |
| Developed by | ETSI (European Telecommunications Standards Institute) & CEN/CENELEC |
| Legal basis | RED Delegated Act (EU 2022/30), activating Directive 2014/53/EU |
| Mandatory compliance | 1 August 2025 — for all radio equipment placed on the EU market |
| Harmonised status | Published in the Official Journal of the EU |
| Conformity route | Harmonised standard presumption of conformity for RED Article 3(3)(d/e/f) |
| Affected products | All internet-connected radio devices (Wi-Fi, Bluetooth, LTE, NB-IoT, Zigbee, etc.) |
The Three Parts of EN 18031
Each part of EN 18031 maps directly to one of the three activated subparagraphs of Article 3(3) of the Radio Equipment Directive:
EN 18031-1 — Network Protection (Article 3(3)(d))
Defines requirements to ensure that radio equipment does not harm the network or misuse network resources. This is the broadest part of the standard and applies to any device that connects to the internet.
Key requirements include:
- Access control — The device must verify the identity of parties before granting access to local or network services.
- Unique credentials — No shared default passwords across device units; each device must have a unique identifier and credential.
- Minimal attack surface — Unused network interfaces, services, and ports must be disabled by default.
- Secure communication — Data transmitted over networks must be protected against interception and tampering.
- Software integrity — The device must verify the authenticity and integrity of software before execution (Secure Boot).
- Software update mechanism — Updates must be delivered over authenticated and encrypted channels.
- Resilience — The device must remain functional despite network disruptions and resist denial-of-service attacks.
EN 18031-2 — Privacy Protection (Article 3(3)(e))
Defines requirements for devices that process personal data, traffic data, or location data. Covers all devices that collect, store, or transmit personal information.
Key requirements include:
- Data minimisation — The device must only collect and store data that is strictly necessary for its intended function.
- Confidentiality of personal data — Stored personal data must be protected against unauthorised access with appropriate encryption.
- Consent and transparency — Users must be informed about data collection; telemetry and tracking features must be opt-in.
- Secure deletion — The device must provide a mechanism to securely erase personal data (factory reset).
- Access controls for personal data — APIs and interfaces exposing personal data must require authentication.
EN 18031-3 — Anti-Fraud Protection (Article 3(3)(f))
Defines requirements for devices capable of initiating financial transactions — including payment terminals, smart meters, and any device integrated with payment systems.
Key requirements include:
- Transaction authentication — Financial transactions must be authenticated through multi-factor or cryptographic mechanisms.
- Tamper evidence — Devices must detect and respond to physical tampering attempts.
- Secure key storage — Cryptographic keys used for transaction authorisation must be stored in hardware-protected storage.
- Audit trail — Transaction logs must be maintained with integrity protection.
Which Part Applies to Your Product?
| Product Type | EN 18031-1 | EN 18031-2 | EN 18031-3 |
|---|---|---|---|
| Wi-Fi / Bluetooth sensor (no personal data, no payments) | ✅ Mandatory | ❌ | ❌ |
| Smart home hub collecting usage data | ✅ Mandatory | ✅ Mandatory | ❌ |
| Wearable health device with personal health data | ✅ Mandatory | ✅ Mandatory | ❌ |
| Smart payment terminal | ✅ Mandatory | ✅ Mandatory | ✅ Mandatory |
| NB-IoT industrial sensor (private network, no PII) | ✅ Mandatory | ❌ | ❌ |
Relationship to Other Standards and Regulations
EN 18031 does not exist in isolation — it forms part of a broader EU cybersecurity regulatory landscape:
| Standard / Regulation | Relationship to EN 18031 |
|---|---|
| ETSI EN 303 645 | Predecessor baseline standard for consumer IoT; EN 18031 supersedes it as the harmonised route for RED compliance |
| CRA (EU 2024/2847) | Parallel regulation covering all products with digital elements; EN 18031 compliance provides partial overlap but is not a substitute |
| IEC 62443 | Industrial automation security standard; referenced by CRA but not by RED |
| ISO/IEC 27001 | Organisational information security; not a product standard, but supports NIS2 requirements |
Critical distinction: The RED Delegated Act and the CRA are separate legal instruments. A product fully compliant with EN 18031 is not automatically CRA-compliant — manufacturers must address both under their respective timelines.
How Compliance Is Demonstrated
For radio equipment manufacturers, there are two routes to demonstrating conformity with EN 18031:
-
Self-declaration — If the manufacturer applies the harmonised EN 18031 standard and maintains a complete technical file demonstrating conformity with each requirement, they can self-declare conformity (EU Declaration of Conformity) and affix the CE mark.
-
Third-party assessment — If no harmonised standard is applied, manufacturers must undergo an EU-type examination by a Notified Body under Annex IV of the Radio Equipment Directive.
For most manufacturers, the harmonised standard route (EN 18031 self-declaration) is the preferred path — but requires a complete and thorough gap analysis against each security requirement.
Hardware Implications of EN 18031
Many EN 18031-1 requirements cannot be satisfied through firmware alone on existing hardware platforms. Key hardware considerations include:
Secure Boot (EN 18031-1, Software Integrity)
Requires that the device cryptographically verifies firmware before execution. If the MCU or SoC does not support hardware-anchored secure boot (e.g., via OTP-fused root keys), retrofitting this capability is impossible without a hardware redesign.
Unique Per-Device Credentials (EN 18031-1, Access Control)
Requires that each device ships with a unique identifier and credential — not a shared default password. If the device has no secure provisioning infrastructure (e.g., no HSM-based key injection during manufacturing), meeting this requirement requires a manufacturing process change alongside hardware supporting secure key storage.
Hardware-Secured Key Storage (EN 18031-3, Anti-Fraud)
For devices requiring anti-fraud compliance, cryptographic keys must be stored in hardware-protected storage — a Secure Element or HSM. An MCU with only software-accessible flash memory cannot meet this requirement.
OTA Update Signing Infrastructure
Authenticated software updates (EN 18031-1) require a signing key chain. If the device cannot verify update package signatures using a hardware-anchored trust anchor, the signed update mechanism is cryptographically weak.
Compliance Timeline and Transition
| Date | Event |
|---|---|
| February 2022 | EU 2022/30 Delegated Act published |
| February 2024 | EN 18031 series finalised and harmonised |
| 1 August 2025 | Full compliance mandatory — radio equipment placed on EU market must conform to RED Article 3(3)(d/e/f) |
| Post-August 2025 | Non-compliant radio equipment must be withdrawn from the EU market |
A transitional period allowed manufacturers to continue selling products under the previous regime, but this transition ended on 1 August 2025. Any product currently in development or preparing for market launch must be EN 18031-compliant before CE marking.
From Our Experience
Working directly with hardware manufacturers on EN 18031 gap analyses, these are the recurring patterns we encounter in practice:
Secure Boot OTP fuse silent failures. On several ARM Cortex-M projects, the chip vendor’s production tooling documented OTP fuse blowing for the secure boot root key — but silently failed to permanently lock the fuse in a specific temperature-voltage corner during board-level manufacturing. The device appeared to boot securely in lab conditions but remained fully unlockable via JTAG in the field. We now mandate a dedicated fuse-verification step in every production test fixture: after programming, the fixture re-reads fuse state and rejects any board where the lock bit is not confirmed set. This is not mentioned anywhere in the EN 18031 standard itself, but it is a real manufacturing failure mode.
“We’ll handle provisioning later” — the most expensive EN 18031 mistake. The unique per-device credential requirement (EN 18031-1 access control) is frequently treated as a software problem to solve post-silicon. In practice, it requires a hardware secure element or at minimum a factory-provisioned key stored in eFuse-protected memory — and production provisioning infrastructure using an HSM. When manufacturers reach this realisation at the start of mass production rather than at PCB design stage, it typically means a board spin or a 3–4 month delay while provisioning infrastructure is built.
EN 18031-2 applicability is wider than manufacturers expect. We routinely see manufacturers classify a product as “no personal data, EN 18031-2 not applicable” — only for the gap analysis to reveal that the device logs Wi-Fi MAC addresses from nearby networks during scanning, or stores the user’s home network SSID. Both are personal data under GDPR and trigger EN 18031-2. Performing the data flow mapping exercise early — before firmware architecture is finalised — avoids costly design changes.
The NB-IoT / LTE-M private network argument. Some industrial IoT manufacturers argue that a device on a dedicated private APN does not “connect to the internet” and therefore EN 18031-1 does not apply. This is a risk: the standard’s scope covers any device with internet connectivity capability at the radio module level, regardless of network configuration. We recommend treating this as a notified body question early, not a self-declared exclusion.
Related Terms
- RED Delegated Act — The legal instrument that made EN 18031 compliance mandatory.
- Radio Equipment Directive (RED) — The parent directive governing radio equipment CE marking.
- Secure Boot — Core technical requirement mapped to EN 18031-1.
- Hardware Root of Trust — Required for EN 18031-1 software integrity compliance.
- OTA Update — Secure update mechanisms required by EN 18031-1.
- CRA — Parallel EU regulation with overlapping but distinct requirements.
Official Sources
- EN 18031-1 — ETSI portal (free download)
- RED Delegated Act EU 2022/30 — EUR-Lex full text
- Harmonised standards list for RED — European Commission
- RED Article 3(3) activation — Official Journal EUR-Lex
Inovasense offers EN 18031 gap analysis and compliance architecture design for radio equipment manufacturers. We assess your hardware’s secure boot capabilities, credential provisioning process, and OTA update infrastructure against each EN 18031-1/2/3 requirement — and specify any hardware changes required before PCB layout is finalised, so you avoid costly hardware revisions after market entry. See our EU Compliance services or our embedded security expertise.