Kbuca What You Need To Know Shelly And EU Red

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 requirements take effect, why they matter, and what our customers can expect as a result.

At Shelly, we are actively aligning with the new RED requirements to ensure our devices remain compliant, secure, and reliable. This article details how these requirements affect the behavior of Shelly devices, and outlines the key changes customers should be aware of.

Starting with firmware version 1.8, the changes described below take effect for newly produced devices. Each change below is marked with Applies to, so you can quickly see whether it affects a new device or a device you already own that gets updated to firmware 1.8+.

Some of these changes affect the traditional behavior of Shelly devices. We have made every effort to minimize disruption for our users while meeting the security guarantees required by the standard.

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

The Radio Equipment Directive (2014/53/EU) is EU legislation that sets essential requirements for radio equipment placed on the EU market, covering health and safety, electromagnetic compatibility, and efficient use of the radio spectrum.

In 2022, the European Commission adopted Delegated Regulation (EU) 2022/30, which activated three additional essential requirements under Article 3(3) of the Directive, specifically for internet-connected radio equipment:

• Article 3(3)(d) - network protection: radio equipment must not harm the network or its functioning, nor misuse network resources in a way that causes unacceptable degradation of service.

• Article 3(3)(e) - personal data and privacy protection: safeguards must ensure the protection of personal data and privacy of the user.

• Article 3(3)(f) - fraud protection: radio equipment used for monetary transactions must include safeguards against fraud.

Compliance with these three requirements became mandatory on 1 August 2025.

The EN 18031 series is the harmonized European standard manufacturers use to demonstrate compliance with these three requirements. It consists of three parts, each corresponding to one requirement:

• EN 18031-1 - network protection (Article 3(3)(d))

• EN 18031-2 - personal data and privacy protection (Article 3(3)(e))

• EN 18031-3 - fraud protection (Article 3(3)(f))

Shelly's ESP32-based, IP-connected devices fall under the scope of EN 18031-1.

Source: Radio Equipment Directive - European Commission, Directive 2014/53/EU - EUR-Lex

Quick Glossary:

• TLS (Transport Layer Security) - the encryption protocol that secures data in transit between the device and the client/server.

• HTTPS / WSS - the encrypted versions of HTTP and WebSocket. WSS stands for "WebSocket Secure." See Outbound WebSocket documentation.

• RPC (Remote Procedure Call) - the JSON-based protocol Shelly Gen2+ devices use to receive commands and report status. See RPC Protocol documentation.

• MQTTS - MQTT (a lightweight messaging protocol commonly used in IoT) over a secure, encrypted TLS connection. See MQTT documentation.

• OTA (Over-the-Air) update - a firmware update delivered to the device remotely, without a physical/wired connection.

• CA chain / private CA - the "chain of trust" used to verify that a certificate is genuine. Shelly issues device certificates from its own private Certificate Authority (CA), separate from public CAs used by typical websites.

• "Just Works" bonding - a simple Bluetooth Low Energy (BLE) pairing method that requires no passkey confirmation from the user; it is convenient but was previously unencrypted.

Changes for Alignment with RED

This section covers the security enhancements Shelly is implementing to achieve compliance with EN 18031-1 for our IP-connected (currently ESP32-based) devices.

These changes improve the security of certificate and secrets storage, data at rest and in transit, and the initial device provisioning process. As a result, some established device behaviors will change.

Secure storage and secrets protection

• Applies to: newly produced devices only.

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

  • Hardware flash encryption is enabled with unique, secure key provisioning at the point of manufacturing.

Impact for users

• Certificates and secrets are protected at rest.

• Re-flashing devices with custom firmware is still possible, but factory provisioning data cannot be recovered afterward.

Warning: If you flash a device with custom firmware and later flash it back to Shelly firmware, full device functionality (including access to Shelly Cloud) will not be restored, because the original factory provisioning data is permanently lost. This cannot be undone.

Enforce secure communication

• Applies to: all devices updated to firmware 1.8+, and newly produced devices.

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

  • TLS validation of outbound HTTPS and MQTTS connections checks hostname, date/time, and the 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 a deliberate action from an authorized user.

Impact for users

• The device's built-in HTTP server now uses TLS and moves to https://.

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

• Browsers and other clients may show a certificate trust warning. The certificate is issued by Shelly's private CA. Shelly will publish the chain of trust for import into your client; the Shelly app will include this chain of trust by default.

Harden authentication and limit setup window

• Applies to: all devices updated to firmware 1.8+, and newly produced devices.

  • Failed login attempts trigger exponential backoff (e.g., 10s → 30s → 60s → 5m).

  • Rate limiting applies to all authentication endpoints.

  • Accounts lock after repeated failures within a time window; only already-established sessions remain valid.

  • A 15-minute setup window opens on power cycle and factory reset. After 15 minutes, unauthenticated access is impossible until a physical reset.

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

Impact for users

• Automated password-guessing and brute-force attempts become significantly harder.

• Initial configuration (admin password, Wi-Fi, etc.) must be completed within the 15-minute window after powering up or resetting the device.

Bluetooth pairing security

Applies to: all devices updated to firmware 1.8+, and newly produced devices.

• Bluetooth pairing moves from plain ("Just Works") unencrypted communication to encrypted communication, without adding extra steps for the user.

Summary of changes

• HTTPS/WSS by default - TLS 1.2 protects the web interface and WebSocket traffic; HTTP on port 80 redirects to HTTPS on 443.

• Per-device certificate - each device is provisioned at production with a certificate from Shelly's internal CA, stored in encrypted flash alongside other secrets (e.g., Cloud token, Zigbee install codes). (New devices only.)

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

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

• Bluetooth safety defaults - Bluetooth is disabled after setup; re-enabling it opens a 15-minute pairing window.

• Encrypted Bluetooth pairing - pairing moves from unencrypted to encrypted communication.

• Provisioning status - a new provision property reflects setup state (e.g., pending, locked), so apps and automations can read a device's security posture directly.

Questions?

If you have questions about how these changes affect your specific setup or integration, contact Shelly Support.