Radio Equipment Directive
The EU Radio Equipment Directive's cybersecurity requirements go live July 15, 2025. If you make connected devices—anything from routers to baby monitors—you need secure-by-design controls, vulnerability management, and conformity documentation or you will not be selling in the EU.
Editorially reviewed for factual accuracy
The EU Radio Equipment Directive's cybersecurity requirements go live July 15, 2025.
Regulatory scope and deadline
The delegated regulation under the EU Radio Equipment Directive (RED) imposes mandatory cybersecurity requirements for radio equipment that can communicate over the internet, process personal or traffic data, or operate network-connected child monitoring functions. After a postponement, the compliance cutover takes effect on 15 July 2025.
From this date, manufacturers placing covered products on the EU market must ensure conformity with Articles 3(3)(d), (e), and (f), covering protection against fraud, safeguarding of personal data and privacy, and prevention of harm to networks. National market surveillance authorities will expect demonstrable governance, technical controls, and documentation. Boards of manufacturers, importers, and authorized representatives must oversee setup to avoid enforcement action, product recalls, and reputational damage.
Compliance requires secure-by-design development, vulnerability management, software update mechanisms, access control, logging, and incident response capabilities. Firms must produce technical documentation, EU declarations of conformity, and supporting evidence demonstrating compliance with harmonized standards such as EN 303 645 or equivalent state-of-the-art controls. Governance structures must ensure that product development, cybersecurity, legal, and supply chain teams coordinate effectively.
Governance framework and accountability
Boards should set up a RED cybersecurity compliance program with clear executive sponsorship, typically from the Chief Product Security Officer or Chief Technology Officer. Governance documentation must include program charters, steering committee membership, meeting cadence, and escalation routes. Responsibility matrices should map regulatory clauses to accountable product leads, security engineers, compliance officers, and legal reviewers. Evidence packs should show board oversight, challenge on readiness status, and approval of budgets for remediation.
Manufacturers must integrate RED obligations into corporate risk management frameworks. Risk appetite statements should address product security, privacy, and supply-chain integrity. Audit committees need visibility into assurance coverage, including internal audit plans focused on product security, software lifecycle controls, and documentation quality. Subsidiary and contract manufacturer oversight must be documented, ensuring consistent application of requirements across the value chain.
Secure development lifecycle and technical controls
Compliance depends on embedding cybersecurity into product development. Teams should maintain secure development lifecycle (SDL) policies covering threat modeling, secure coding standards, peer reviews, static and dynamic testing, and penetration testing. Evidence packs must include SDL process documentation, training records, tool configurations, and sample artifacts. Threat models should map attack vectors, abuse cases, and mitigations for connectivity modules, authentication flows, and data storage.
Technical controls must address access control, encryption, secure boot, firmware integrity, and protection against unauthorized configuration changes. Manufacturers should document cryptographic standards, key management procedures, and hardware security features. Logs should capture security-relevant events with secure storage and tamper resistance. Evidence should show testing of logging mechanisms, alert thresholds, and integration with security operations centers or managed detection services.
Software updates and vulnerability management
Article 3(3)(e) requires appropriate protection of personal data and privacy, including mechanisms for secure updates and vulnerability remediation. Manufacturers must maintain documented update policies, including signing procedures, distribution channels, rollback strategies, and communication plans. Governance packs should include maintenance schedules, support timelines, and end-of-life policies. Firmware and software update processes must show end-to-end integrity, with evidence of code signing, secure transport, and user notification workflows.
Vulnerability management programs should incorporate intake channels (bug bounty, security researcher coordination, customer reports), triage procedures, severity ratings, and remediation timelines. Boards should review vulnerability dashboards showing backlog, mean time to remediate, and exposure analysis. Evidence rooms must store vulnerability reports, root-cause analyzes, fix validation results, and disclosure communications in line with Coordinated Vulnerability Disclosure good practices.
Privacy and data protection controls
RED obligations intersect with GDPR requirements. Manufacturers must show privacy-by-design principles, data minimization, and secure processing. Governance documentation should include data protection impact assessments (DPIAs) for device features, consent management flows, and user interface designs. Evidence should show pseudonymization or anonymization techniques, retention schedules, and user rights handling procedures.
Legal and privacy teams must guide on cross-border data transfers, integration with mobile apps or cloud services, and transparency obligations. Teams should store sample privacy notices, terms of service, and customer support scripts addressing privacy queries. Boards need assurance that privacy controls are tested, monitored, and aligned with corporate compliance frameworks.
Supply chain and manufacturing oversight
Manufacturers often rely on contract manufacturers, component suppliers, and software partners. Supply-chain governance must ensure that third parties comply with cybersecurity requirements. Evidence packs should include supplier risk assessments, audit reports, contractual clauses mandating security controls, and corrective action plans. Teams should maintain bills of materials (hardware and software) with version tracking, vulnerability data, and support status.
Secure provisioning processes must cover device identity, certificate management, and secure manufacturing lines. Documentation should describe key injection procedures, factory acceptance tests, and tamper detection controls. Boards should review reports on supplier readiness, audit findings, and remediation progress.
Testing, certification, and conformity assessment
Manufacturers must show compliance through testing and conformity assessment. Teams should adopt harmonized standards where available (for example, EN 303 645, ETSI TS 103 701) or provide technical justifications for alternative controls. Testing plans must cover functional security requirements, penetration testing, fuzzing, interoperability, and resilience assessments. Evidence should include test plans, laboratory reports, issue logs, and closure evidence.
Technical documentation should compile product descriptions, risk assessments, design schematics, software architecture diagrams, test results, and instructions for safe use. Manufacturers must produce EU declarations of conformity referencing applied standards and maintain them for at least ten years. Governance packs should include document control procedures, version histories, and access controls to protect proprietary information.
Market surveillance readiness and incident reporting
National authorities can request documentation, perform inspections, or require sample testing. Teams must maintain an evidence room with indexed documentation ready for rapid retrieval. Response plans should define roles, communication protocols, and legal review processes for authority requests. Boards should review readiness drills, ensuring teams can produce documentation within statutory timelines.
Incident reporting workflows must align with RED obligations, the NIS2 Directive where applicable, and sector-specific regulations. Teams should maintain incident classification criteria, escalation matrices, and notification templates for authorities, customers, and partners. Evidence should include incident response plans, tabletop exercise reports, and lessons learned. Integration with product security incident response teams (PSIRT) is essential to provide timely containment, investigation, and remediation.
Post-market surveillance and monitoring
Manufacturers must monitor products in the field to detect emerging vulnerabilities, misuse, or safety issues. Post-market surveillance plans should define data sources (telemetry, customer support, social media, reseller feedback), analysis methods, and escalation triggers. Boards should review surveillance dashboards, trend analyzes, and remediation plans. Evidence packs must include monitoring procedures, alert thresholds, and response logs.
Customer support teams need playbooks for handling security-related enquiries, warranty claims, and returns. Teams should document authentication procedures for callers, escalation paths to security teams, and guidance for applying patches or replacements. Training records should show that support staff understand security protocols and privacy obligations.
Training, culture, and communication
Effective compliance requires skilled staff and strong security culture. Training programs must cover RED cybersecurity requirements, secure development practices, incident response, and supplier management. Evidence should include training materials, attendance logs, competency assessments, and refresher schedules. Teams should monitor culture indicators such as secure coding audit results, whistleblower reports, and employee feedback.
Communication plans should address internal teams, partners, and customers. Manufacturers must provide clear user guidance on secure configuration, updates, and incident reporting. Marketing materials and packaging should align with regulatory claims and not overstate security features. Boards should oversee communication strategies to prevent misleading statements that could trigger enforcement or liability.
Integration with broader compliance environment
RED cybersecurity requirements intersect with other regulations and standards, including the Cyber Resilience Act, NIS2, GDPR, and sectoral mandates. Governance documentation should map dependencies, ensuring consistent controls and avoiding duplication. Teams must coordinate with teams managing CE marking, product safety, and export controls. Evidence should show how shared controls (for example, vulnerability management, incident response) operate across regulatory frameworks.
By 15 July 2025, manufacturers must be able to show a full governance ecosystem encompassing secure development, documentation, supply-chain oversight, and incident response. Boards that maintain rigorous evidence packs, run rehearsal exercises, and enforce accountability across the product lifecycle will be prepared for market surveillance scrutiny and can position their connected devices as trustworthy in the EU market.
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Network Security Fundamentals Explained Practically
A practitioner-focused guide to network security fundamentals covering firewalls, segmentation, IDS/IPS, DNS security, VPNs, wireless security, zero trust architecture, and traffic…
-
Complete Beginner Cybersecurity Guide for Home Users
A practical cybersecurity guide designed for non-technical home users. Covers threat awareness, home network security, password management, multi-factor authentication, device…
-
Cybersecurity Operations Playbook
Use our research to align NIST CSF 2.0, CISA KEV deadlines, and sector mandates across threat intelligence, exposure management, and incident response teams.
Documentation
- Commission Delegated Regulation (EU) 2022/30 — eur-lex.europa.eu
- Commission Delegated Regulation (EU) 2023/2445 — eur-lex.europa.eu
- ETSI EN 303 645 V2.1.1 — etsi.org
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.