What you need to know - Shelly and Radio Equipment Directive (RED) standard EN 18031-1

Introduction

The purpose of this article is to provide a clear overview of the newly enforced Radio Equipment Directive (RED) standard EN 18031-1 and its cybersecurity requirements as they relate to Shelly devices.

We will explain when and how these standards take effect, why they matter, and the importance of clearly communicating to our clients what to expect.

At Shelly, we are actively aligning with the new RED requirements to ensure our devices remain compliant, secure, and reliable. This article will also detail how the implementation of these standards will impact the behavior of Shelly devices, outlining the key changes our customers can expect moving forward.

Starting with firmware version 1.8 of our devices the below mentioned changes will be in effect for newly produced devices and will partially apply to devices that are updated to this version of firmware.

Explaining Radio Equipment Directive (RED) (2014/53/EU) EN 18031-1

EN 18031 is a series of European cybersecurity standards for radio equipment, harmonized under the Radio Equipment Directive (RED) (2014/53/EU). Specifically, EN 18031-1 focuses on internet-connected radio equipment, addressing network protection and service integrity. It is part of the broader effort to enhance cybersecurity for radio equipment and protect user data and networks. 

Here's a more detailed breakdown:

• Purpose:

  EN 18031 provides a framework for manufacturers to demonstrate compliance with the RED's cybersecurity requirements, particularly Articles 3.3(d), (e), and (f). 

• Harmonization:

  The EN 18031 series, including EN 18031-1, has been officially harmonized with the RED, meaning compliance with these standards can be used to demonstrate conformity with the directive

• Scope:

  EN 18031-1 specifically addresses internet-connected radio equipment, outlining requirements for protecting networks from harmful interference and misuse of network resources. 

• Key Areas:

  It covers aspects like secure storage mechanisms, secure communication, and resilience mechanisms. 

• Mandatory Application:

  The cybersecurity requirements of the RED, including those addressed by EN 18031, became mandatory on August 1, 2025. 

• Relationship to Cyber Resilience Act:

  The EN 18031 standards are also seen as a foundation for future cybersecurity standards related to the Cyber Resilience Act. 

Changes for alignment to RED

This section covers the implementation of the security enhancements required to achieve RED certification compliance for IP-connected (currently ESP32-based) devices according to the EN 18031-1 standard.

How this will reflect Shelly’s - it will improve security, storage of certificates, secrets and data at rest and in transit as well as the security of the initial provisioning process. Inevitably there will be change in the established behavior of our devices.

Below are changes Shelly is going to implement and how this will affect devices behavior.

Secure storage and secrets protection

• Security assets (shared secrets, private keys, certificates) are stored in encrypted flash.

• Secrets used for accessing networks are stored securely.

• Shared keys used to access the device are stored securely.

• The hardware flash encryption is enabled with unique secure key-provisioning in manufacturing.

Impact for users

• Certificates and secrets are protected at rest.

• Re-flashing devices with custom firmware is still possible but factory provisioning data can not be recovered. Flashing back with Shelly firmware will not restore full device functionality (access to Shelly cloud) as the contents of factory data will be lost.

Enforce secure communication

• HTTPS and WSS for accessing the device web server are enforced; plain HTTP/WS is redirected to HTTPS/WSS.

• TLS validation of outbound HTTPS and MQTTS connections checks include hostname, date/time and full CA chain; the built-in CA store can be updated via OTA. TLS validation is enabled by default and can only be disabled by deliberate action of an authorized user.

Impact for users

• HTTP server on the device uses TLS and moves to https://.

• Integrations using WebSockets access to the built in HTTP server must switch to wss://.

• Browsers and other clients may warn about certificate trust chain validation problem. The certificate is issued by Shelly private CA. Shelly will publish the chain of trust for importing into your client. Shelly application will have this chain of trust by default.

Harden authentication and limit setup window

• Curtail password guessing using multiple authentication attempts - Implement exponential backoff for failed logins (e.g., 10s → 30s → 60s → 5m).

• Rate-limiting on all authentication endpoints.

• Account lockout after repeated failures within a time window, only established sessions are allowed.

• 15-minute setup window on power cycle and factory reset; After 15 min elapse, unauthenticated access is impossible until a physical reset.

• Bluetooth channel is automatically disabled after setup; enabling it opens a 15-minute pairing window only.

Impact for users

• Fewer chances for automated guessing/brute-force attempts.

• You must complete initial configuration (admin password, Wi-Fi, etc.) within the guided 15-minute window after powering up/resetting the device.

List of changes

• HTTPS/WSS by default: the web interface and WebSocket traffic are now protected with TLS 1.2. HTTP on port 80 redirects to HTTPS on 443.

• Per-device certificate: devices are provisioned at production with a certificate issued by our internal CA and store it in encrypted flash (same protection as other secrets like CloudToken/Zigbee install codes).

• Hardened authentication: progressive delays, rate-limits on all auth endpoints (WebUI/RPC/WebSockets), and account lockout after repeated failures.

• Time-limited setup window: after power-up/reset there is a 15-minute setup period; afterwards unauthenticated RPC access is locked until a physical reset.

• Bluetooth safety defaults: Bluetooth is disabled after setup; when you manually re-enable it, pairing is available only for 15 minutes.

• Bluetooth “Just works” bonding: Limit unencrypted radio communication. Move from plain communication over BLE to an encrypted one without raising the requirements.

• Provisioning status: the new provision property reflects setup state (e.g., pending, locked) to make the device’s security posture clear in apps/automations.

In conclusion

• Open setup window for all Shelly devices is limited to the first 15 minutes after power cycle.

• All communications are enforced to use a secure channel.

• Firmware, device configuration, secrets, keys are encrypted using factory provided key.