RED Article 3(3)(d)(e)(f) cybersecurity for IoT and radio equipment is in force from 1 August 2025. Learn scope, ETSI EN 303 645 compliance path, and CRA overlap strategy.
The short answer
The Radio Equipment Directive (RED) cybersecurity delegated regulation — Commission Delegated Regulation (EU) 2022/30 — activates Articles 3(3)(d), 3(3)(e), and 3(3)(f) of the RED for internet-connected radio equipment and certain wearables. These requirements became mandatory on 1 August 2025. Manufacturers must self-assess against ETSI EN 303 645 or an equivalent harmonised standard and affix CE marking accordingly.
Scope: which products are covered
RED Article 3(3) cybersecurity applies to radio equipment that:
Product categories in scope (illustrative):
Products explicitly out of scope:
→ CRA Scope Checker also covers RED applicability assessment
- Connects to the internet — directly or via another device (home gateway, smartphone, hub)
- Is covered by Delegated Regulation (EU) 2022/30, which covers:
- Radio equipment capable of communicating via the internet
- Wearable radio equipment (smartwatches, fitness trackers, medical wearables)
- Radio equipment designed for children (toys, educational devices)
- Consumer IoT: smart speakers, smart TVs, connected appliances, smart home hubs
- Wearables: smartwatches, fitness bands, connected health monitors
- Baby monitors and childcare equipment with connectivity
- Industrial IoT with radio communication interfaces (if consumer-accessible)
- Routers and network equipment for home/SOHO use
- Medical devices (covered by MDR/IVDR — separate regime)
- Motor vehicles (type-approved under Regulation (EU) 2019/2144)
- Aviation equipment
- Radio equipment used exclusively in professional/industrial contexts where end consumers do not have access
Article 3(3)(d) — Network security
Radio equipment must be designed and manufactured to not harm the network or its functioning, and in particular must not misuse network resources, thereby causing an unacceptable degradation of service.
In practice: The device must not be weaponised into a botnet node. It must not consume excessive bandwidth, generate malicious traffic, or participate in DDoS attacks. Secure boot, firmware integrity, and network traffic rate limiting are key controls.
Article 3(3)(e) — Protection of personal data and privacy
Radio equipment must incorporate safeguards to ensure the protection of personal data and privacy of the user and subscriber.
In practice:
This requirement applies even if the device is not classified as processing personal data under GDPR — it is a product design obligation, not a data controller obligation.
- Data minimisation — only collect what is necessary for the stated purpose
- Encryption of personal data in transit and at rest (where applicable)
- Secure credential management (no default credentials)
- Privacy by default configuration
- Clear user controls for data sharing
Article 3(3)(f) — Protection against fraud
Radio equipment must incorporate features to protect against fraudulent use of the device and misuse of network infrastructure.
In practice:
- Authentication mechanisms preventing unauthorised access
- Secure update mechanisms (signed firmware updates)
- Protection against physical tampering where relevant
- Session management and timeout controls
Harmonised standard: ETSI EN 303 645
ETSI EN 303 645 (Cyber Security for Consumer Internet of Things) is the primary harmonised standard supporting RED Article 3(3) compliance. When you comply with a harmonised standard, you benefit from the presumption of conformity — meaning your product is presumed to meet the essential requirements without further justification.
ETSI EN 303 645 v2.1.1 covers 13 provisions:
| # | Provision |
|---|---|
| 5.1 | No universal default passwords |
| 5.2 | Implement a means to manage reports of vulnerabilities (CVD) |
| 5.3 | Keep software updated |
| 5.4 | Securely store sensitive security parameters |
| 5.5 | Communicate securely |
| 5.6 | Minimise exposed attack surfaces |
| 5.7 | Ensure software integrity |
| 5.8 | Ensure that personal data is secure |
| 5.9 | Make systems resilient to outages |
| 5.10 | Examine system telemetry data |
| 5.11 | Make it easy for users to delete user data |
| 5.12 | Make installation and maintenance of devices easy |
| 5.13 | Validate input data |
Testing standard: ETSI TS 103 701 provides the test specification for ETSI EN 303 645.
Conformity assessment and CE marking
Route for most RED Article 3(3) products: Self-assessment by manufacturer (internal production control — Annex II of RED).
Third-party notified body assessment is not required for RED Article 3(3) compliance unless the manufacturer cannot demonstrate compliance using a harmonised standard.
CE marking process:
- Assess against ETSI EN 303 645 (or equivalent)
- Draw up technical documentation
- Draw up EU declaration of conformity (DoC)
- Affix CE marking
- Register product in EPREL (European Product Registry for Energy Labelling) if also covered by energy labelling requirements
Technical documentation requirements
Technical documentation for RED Article 3(3) must demonstrate:
Retention: 10 years after last product placed on the market.
- Product description and intended use
- List of harmonised standards applied (or technical specification used)
- Assessment results against each applicable provision of ETSI EN 303 645
- Test reports (internal or third-party)
- CVD policy (provision 5.2)
- Secure update mechanism description (provision 5.3)
- EU declaration of conformity
RED × CRA overlap
Many IoT products subject to RED Article 3(3) will also be subject to the CRA when it applies from December 2027. The overlap is significant:
| Obligation | RED Art. 3(3) | CRA Annex I |
|---|---|---|
| No default passwords | ETSI EN 303 645 §5.1 | Part I §2(2) |
| CVD policy | ETSI EN 303 645 §5.2 | Part II §1 + Art. 14 |
| Secure software updates | ETSI EN 303 645 §5.3 | Part I §2(7) |
| Data encryption | ETSI EN 303 645 §5.5 | Part I §2(4) |
| Minimal attack surface | ETSI EN 303 645 §5.6 | Part I §2(5) |
| Software integrity | ETSI EN 303 645 §5.7 | Part I §2(1) |
Strategy for dual-regulated products: Implement ETSI EN 303 645 now for RED compliance. Treat it as the foundation for CRA Annex I compliance — the gap from EN 303 645 to full CRA Annex I is significant (CRA adds SBOM, vulnerability reporting, 10-year retention, more detailed security requirements) but the overlap means you are not starting from zero.
Key dates
| Date | Event |
|---|---|
| 1 August 2025 | RED Article 3(3)(d)(e)(f) — mandatory for new products placed on the market |
| 1 August 2025 | Products placed on the market before this date had a sell-through period (now expired) |
| 11 September 2026 | CRA Art. 14 vulnerability reporting (relevant for dual RED+CRA products) |
| 11 December 2027 | Full CRA obligations for products with digital elements |
If you placed a product on the market before 1 August 2025 without Article 3(3) compliance: The product can continue to be sold only if it meets the requirements. New production runs must comply. Consult your national market surveillance authority on the specific sell-through position for inventory manufactured before August 2025.
Common compliance gaps
1. CVD policy absent or inactive.
ETSI EN 303 645 §5.2 requires a publicly accessible vulnerability reporting mechanism. A generic security@ email that is unmonitored does not satisfy this.
2. Hardcoded or universal default passwords.
EN 303 645 §5.1 is a hard requirement — no device-type default passwords that are the same across all units. Device-unique defaults (printed on the device) are acceptable.
3. No defined software support period.
EN 303 645 §5.3 requires the manufacturer to define the minimum period during which software updates will be provided and communicate this to the user at point of sale.
4. Firmware update mechanism unsigned or unverified.
§5.7 requires software integrity verification. Unsigned firmware updates create both a compliance gap and a significant security vulnerability.
Tools on NexCyber
- CRA Scope Checker — confirm CRA and RED applicability
- 144-obligation gap assessment — maps RED, CRA, NIS2, AI Act and DORA
Further reading
This page provides regulatory guidance for informational purposes. It is not legal advice. Harmonised standard publication dates and national market surveillance authority interpretations may vary. For compliance decisions, consult the applicable national authority or a qualified legal adviser.
NexCyber — EU Market Access Compliance Platform
- AI Act × CRA overlap
- SBOM requirements under CRA
- CRA Article 14 vulnerability reporting
This is an educational explainer. For the canonical regulation reference, see the dedicated RED page — or run an assessment to see how it applies to your product.