To sell wireless or IoT devices in the European Union, compliance with the Radio Equipment Directive (RED) is mandatory. RED not only focuses on radio frequency performance but also requires devices to have adequate protection measures in terms of network security, user privacy, and software updates.
Overview of RED Certification
- • Scope: Wireless devices in the EU/EEA market, including Wi-Fi, BLE, cellular, Sub-G, and IoT terminals accessing external networks via Ethernet.
- • Core Objectives:
- 1. Effective Use of Radio Spectrum
- 2. Electromagnetic Compatibility and User Safety
- 3. Network Security, Personal Data, and Privacy Protection (Article 3.3 of 2014/53/EU)
Security Key Points of Common Protocols
| Protocol | Common Uses | RED Focus Points | Development Recommendations |
| HTTP/HTTPS | Device cloud management, OTA | Is HTTPS enabled by default? Is certificate validation strict? | Enforce TLS1.2+, validate the complete chain of certificates, prohibit plaintext fallback |
| MQTT | Data reporting, remote control | Broker authentication mechanism, Topic permissions, QoS and replay protection | Use TLS + Client Cert; Topic with ACL; message signing/timestamping |
| SSH | Remote maintenance | Login credential security, log auditing, firmware isolation | Disable password login, use keys; restrict executable commands; log operations |
| RTTY/Remote Terminal | Fault emergency, low bandwidth links | Tunnel encryption, allowed command range, session timeout | Embed RTTY in encrypted tunnels; add MFA and access approval |
HTTP/HTTPS
- • Risk Points: Default use of HTTP, certificate expiration not notified, hostname verification ignored.
- • RED Recommendations: Enable HTTPS by default; certificate changes must have a management process; provide a secure update mechanism.
MQTT
- • Risk Points: Anonymous connections, plaintext passwords, unstructured Topics.
- • RED Recommendations: Enforce TLS + client certificates; offline devices must have authentication capabilities; prevent message tampering and replay.
SSH
- • Risk Points: Default passwords, debugging accounts not closed, unrestricted command execution.
- • RED Recommendations: Only open necessary ports; use unique key pairs; enable operation auditing and timeout exit.
RTTY / Remote Terminal
- • Risk Points: Plaintext transmission, shared accounts, lack of operation records.
- • RED Recommendations: Transmit through VPN/TLS tunnels; remote operations require identity binding and auditing; support emergency shutdown.
Certificate and Key Management
- 1. Unique Identity: Each device must have a unique certificate or key to avoid mass leakage leading to a network-wide breach.
- 2. Secure Storage: Keys should be stored in a Secure Element or TrustZone/PSA trusted area, plaintext storage in Flash is prohibited.
- 3. Lifecycle Management:
- • Manufacturing Stage: Secure Provisioning, record certificate serial numbers
- • Operational Stage: Support certificate updates, revocation, temporary suspension
- • Disposal Stage: Secure erasure or disablement
How to “Build Compliance In” During Development
Security Design Checklist
- • Default enable encrypted transmission (TLS1.2+/DTLS)
- • Enforce certificate validation, prohibit skipping or “trusting all certificates”
- • Network services use the principle of least privilege, such as MQTT Topic ACL
- • Debug interfaces (Telnet, RTTY, SSH) must have access control and audit logs
Key Steps in Compliance with RED
- 1. Threat Modeling: Use STRIDE/LINDD to assess potential attack paths on protocol interfaces
- 2. Secure Coding Standards: Follow standards like MISRA, CERT C/C++ to avoid common vulnerabilities
- 3. Automated Security Testing: Include static analysis (SAST), dynamic fuzz testing (DAST), certificate validity testing in CI
- 4. Documentation and Traceability: Prepare security design specifications, test records, certificate lists, which are essential materials for RED audits
Typical Issue Handling
| Issue | Audit Feedback | Rectification Plan |
| HTTP port still accessible | “Insufficient assurance of communication security” | Force redirect to HTTPS; add HSTS; close plaintext ports |
| MQTT using fixed username/password | “Weak authentication mechanism, easily spoofed” | Switch to TLS+certificate; enable device-level ACL |
| SSH default password not changed | “Factory configuration has security risks” | Force modification on first startup; provide unique keys |
| Certificate expiration not detected | “Unable to ensure long-term security” | Add certificate status checks; implement automatic updates |
| Remote terminal has no logs | “Lack of traceability” | Introduce auditing services, upload to secure log server |