Skip to content
Inovasense

EN 18031

EN 18031 is the European harmonised standard series defining cybersecurity requirements for radio equipment under the RED Delegated Act — mandatory for CE marking of internet-connected radio products from August 2025.

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

DetailInformation
Standard seriesEN 18031-1, EN 18031-2, EN 18031-3
Developed byETSI (European Telecommunications Standards Institute) & CEN/CENELEC
Legal basisRED Delegated Act (EU 2022/30), activating Directive 2014/53/EU
Mandatory compliance1 August 2025 — for all radio equipment placed on the EU market
Harmonised statusPublished in the Official Journal of the EU
Conformity routeHarmonised standard presumption of conformity for RED Article 3(3)(d/e/f)
Affected productsAll 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 TypeEN 18031-1EN 18031-2EN 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 / RegulationRelationship to EN 18031
ETSI EN 303 645Predecessor 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 62443Industrial automation security standard; referenced by CRA but not by RED
ISO/IEC 27001Organisational 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:

  1. 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.

  2. 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

DateEvent
February 2022EU 2022/30 Delegated Act published
February 2024EN 18031 series finalised and harmonised
1 August 2025Full compliance mandatory — radio equipment placed on EU market must conform to RED Article 3(3)(d/e/f)
Post-August 2025Non-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.

Official Sources

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.