Article 3.3 of the Radio Equipment Directive (RED) Explained
Navigate the EU RED's new IoT security requirements with this detailed breakdown of Article 3.3. Essential reading for manufacturers and developers.

Larry Pesce
VP of Services
The Radio Equipment Directive (RED) (Directive 2014/53/EU) is the European Union’s regulatory framework for radio equipment. It ensures that devices placed on the market meet essential requirements for safety, health, electromagnetic compatibility, and the efficient use of the radio spectrum.
The directive has been in place since 2014, but the cybersecurity provisions inside it sat dormant for years. Article 3(3), first subparagraph, points (d), (e), and (f) only became applicable when Commission Delegated Regulation (EU) 2022/30 activated them for specific categories of radio equipment. Article 3.3 attaches additional essential requirements to equipment that intentionally transmits or receives radio waves for communication or radiodetermination purposes.
The requirements have applied since August 1, 2025. Radio equipment in the covered categories that reaches the EU market without meeting them is non-compliant now, not at some future date, and market access across the European Economic Area (EEA) depends on closing that gap.
What Do RED Articles 3.3(d), (e), and (f) Cover?
Article 3.3 of the RED directive mandates additional cybersecurity and safety measures for radio equipment. It introduces three key provisions that IoT manufacturers must comply with:
- Article 3.3(d): Prevents radio equipment from harming networks or misusing network resources, ensuring that devices do not cause unacceptable service degradation.
- Article 3.3(e): Requires safeguards to protect personal data and user privacy, reinforcing alignment with GDPR and other data protection regulations.
- Article 3.3(f): Mandates protections against fraud, particularly for devices that handle financial transactions or sensitive user interactions.
For IoT manufacturers, this means integrating security mechanisms at both the hardware and software levels to meet compliance standards.
Why RED Article 3.3 Matters for IoT Devices
The implementation of Article 3.3 represents a significant shift in IoT device regulation. While compliance requires investment and resource allocation, it ultimately benefits both manufacturers and consumers by:
- Establishing clear security standards
- Building consumer trust in IoT devices
- Creating a more secure IoT ecosystem
- Harmonizing security requirements across the EU market
What RED Cybersecurity Measures Are Essential for IoT Devices?
To comply with Article 3.3, manufacturers must implement the following security measures:
1. Network Protection Requirements (Article 3.3(d))
Connected devices must incorporate safeguards to protect networks from harm.
- Devices must prevent unauthorized network access or interference.
- Implement encryption and authentication protocols to secure device-to-network communications.
- Ensure software updates and patches do not degrade network performance.
- Implement features that ensure their devices cannot be used to disrupt network services or compromise network infrastructure.
2. Data Protection and Privacy (Article 3.3(e))
Privacy considerations are at the forefront of Article 3.3.
- Devices must incorporate data encryption, secure storage, and privacy controls to prevent unauthorized access.
- Compliance with GDPR is necessary to align with EU data protection laws.
- Secure transmission methods must be in place to protect personal data from interception.
- Manufacturers must adopt a "privacy by design" approach, making data protection an integral part of device development rather than an afterthought.
3. Fraud Prevention (Article 3.3(f))
The directive requires measures to prevent financial fraud through or against these devices.
- Devices handling financial transactions must implement anti-fraud mechanisms such as secure payment processing and two-factor authentication.
- Strong identity verification methods should be used to protect user credentials.
- Security testing and vulnerability assessments must be conducted regularly to detect potential fraud risks.
How Do You Prove RED Compliance? Conformity Assessment and Documentation
Achieving compliance with Article 3.3 requires a comprehensive approach to device security. Manufacturers must prepare detailed technical documentation demonstrating how their devices meet these requirements. This includes:
- Detailed product specifications
- Risk assessment documentation
- Test reports and certification results
- Design and manufacturing information
- Compliance declarations
Additionally, IoT manufacturers must undergo a conformity assessment procedure before a product is released to the market. Depending on the device category and risk level, this may involve self-assessment or review by a notified body. The assessment verifies that all essential requirements are met, leading to CE marking authorization.
RED Cybersecurity Compliance Deadline (Article 3.3)
Delegated Regulation (EU) 2022/30 made Articles 3.3(d), 3.3(e), and 3.3(f) applicable from August 1, 2025. The date moved once before it landed there, which is why older guidance still circulates citing August 2024. Equipment placed on the EU market since that date has been subject to the requirements, and market surveillance authorities can assess it against them.
A second date now matters as much as the first. The provisions are scheduled to be repealed on December 11, 2027, and the section below covers what replaces them.
Which Harmonized Standards Apply, and Where the Restrictions Bite
Most coverage treats EN 18031 as the box you tick to self-declare. The Official Journal listed all three parts with restrictions attached, and those restrictions decide whether you sign your own Declaration of Conformity or sit in front of a notified body.
CEN and Cenelec drafted the series in response to a 2022 standardisation request. The Commission cited all three parts in Annex I to Implementing Decision (EU) 2022/2191 through Implementing Decision (EU) 2025/138, adopted January 28, 2025 and published two days later.
| Standard | Supports | Equipment covered |
|---|---|---|
| EN 18031-1:2024 | Article 3(3)(d), harm to the network | Internet connected radio equipment |
| EN 18031-2:2024 | Article 3(3)(e), personal data and privacy | Internet connected, childcare, toys, and wearable radio equipment |
| EN 18031-3:2024 | Article 3(3)(f), protection from fraud | Internet connected radio equipment processing virtual money or monetary value |
Applying a cited harmonized standard in full gives you a presumption of conformity. Four restrictions carve holes in that presumption, and they are where most programs get caught.
- Rationale and guidance sections, all three parts. These sections explain why a risk matters and illustrate how it might be mitigated. They set out no specifications, so they confer no presumption of conformity. An assessment that leans on them has not demonstrated anything.
- Default passwords, clauses 6.2.5.1 and 6.2.5.2, all three parts. Both clauses give manufacturers the option of allowing a user to skip setting a password entirely. Implement that option and the presumption falls away for the relevant requirement.
- Parental and guardian access control, EN 18031-2. For equipment covered by clauses 6.1.3 through 6.1.6, the access control implementation categories include role-based, discretionary, and mandatory control. Some of those are incompatible with parental or guardian control. Where applying clauses 6.1.3.4.2, 6.1.4.4.2, 6.1.5.4.2, and 6.1.6.4.2 leaves parental or guardian access control unensured, point (e) is not presumed met.
- Secure updates, EN 18031-3 clause 6.3.2.4. This one is unconditional. The clause offers four implementation categories for secure updates, based on digital signatures, secure communication, access control, or others. The Commission concluded that none of them alone is sufficient where financial assets are involved, so the assessment criteria confer no presumption of conformity with point (f) at all.
Read the last one again if you ship a device that moves money or virtual currency. There is no configuration of clause 6.3.2.4 that earns you the presumption. Where a harmonized standard is not applied, or is applied only in part, the RED's conformity assessment procedures route you to a notified body.
That is the practical test. Not whether you used EN 18031, but whether any restriction touches your product.
What Changes on December 11, 2027
The obligation does not expire. It moves.
Commission Delegated Regulation (EU) 2026/339, adopted February 16, 2026 and published in the Official Journal on April 29, 2026, repeals Delegated Regulation (EU) 2022/30 with effect from December 11, 2027. That is the same date the Cyber Resilience Act becomes fully applicable.
The reasoning is stated plainly in the recitals. The essential cybersecurity requirements in Annex I to the CRA include all the elements of the requirements in Article 3(3), points (d), (e), and (f). Leaving both instruments live would subject the same radio equipment to two cybersecurity regimes at once, so the Commission removed one.
Three consequences follow, and the first is the one teams get wrong.
- The transition window is fully enforceable. Radio equipment placed on the Union market between August 1, 2025 and December 10, 2027 remains subject to the Article 3(3)(d), (e), and (f) requirements. Recital 5 of the repealing regulation states that the repeal does not affect Union market surveillance and control of that equipment. A product you ship in 2026 stays assessable against RED after the RED rules are gone.
- Your presumption of conformity has a shelf life. EN 18031 confers presumption only while the underlying requirements apply under the RED. The Commission has indicated that the cybersecurity standard references will be removed from Annex I to Implementing Decision (EU) 2022/2191 after the repeal takes effect.
- The evidence transfers, the paperwork does not. CRA conformity runs on its own technical documentation, its own Annex I requirements, and its own reporting obligations. What carries over is the underlying artifact: a component inventory you can defend, and a record of which vulnerabilities are actually present in what shipped.
Treating December 11, 2027 as an exit is the expensive reading. A product in design today will be placed on the market under the CRA, and a product shipped today stays answerable under the RED for years. Most portfolios will need both answers at the same time.
What Are the Main Risks of Non-Compliance With RED?
Failing to comply with RED Article 3.3 can result in significant consequences for IoT manufacturers:
1. Regulatory and Legal Risks of RED Non-Compliance
- Non-compliant products may be removed from the EU market.
- Companies could face fines and penalties from regulatory authorities.
- Legal action may be taken by affected consumers or business partners.
2. Market and Reputational Risks
- Consumers increasingly prioritize security; non-compliance can lead to loss of trust and reduced sales.
- Companies that fail to meet cybersecurity requirements may be considered risk-prone, leading to loss of business opportunities and partnerships.
- Security vulnerabilities can lead to data breaches, damage brand reputation, and result in potential lawsuits.
How to Comply With the RED Directive: Step by Step
1. Assessment and Planning
- Conduct an internal security audit to identify gaps in compliance with Article 3.3.
- Build a remediation roadmap for products already on the market, since the requirements have been in force since August 1, 2025.
2. Design and Development
- Integrate security-by-design principles to ensure products are compliant from the development stage.
- Use secure firmware and software development practices to minimize vulnerabilities.
- Implement regular security updates to maintain compliance over time.
3. Testing and Certification
- Work with accredited testing laboratories to verify compliance with the RED.
- Obtain a Declaration of Conformity (DoC) to demonstrate adherence to EU regulations.
- Maintain comprehensive technical documentation detailing compliance measures.
4. Post-Market Surveillance
- Monitor device security after deployment through regular security audits.
- Establish a system for reporting and addressing vulnerabilities.
- Prepare a response plan for handling potential security incidents or compliance breaches.
RED Compliance Best Practices for IoT Manufacturers
To achieve compliance, manufacturers should adopt these key practices:
Security by Design
Integrate security features from the earliest stages of product development. This proactive approach is more cost-effective than retrofitting security features and helps ensure comprehensive protection.
Continuous Assessment
Implement ongoing security testing and validation procedures. Regular assessments help identify and address vulnerabilities before they can be exploited.
Documentation Management
Maintain detailed records of all security measures, test results, and risk assessments. Good documentation practices are crucial for demonstrating compliance and facilitating future updates.
Conclusion
Article 3.3 of the RED directive represents a crucial step toward securing the IoT ecosystem. While compliance may require significant effort, it establishes essential safeguards for networks, personal data, and fraud prevention. Manufacturers who embrace these requirements and implement robust security measures will be well-positioned for success in the evolving IoT landscape.
Finite State is committed to helping IoT manufacturers navigate these evolving regulations by providing industry-leading software supply chain security solutions. Contact us today to learn more about how we can support your compliance efforts.
Tags

Larry Pesce
VP of Services
Larry Pesce is a lifelong hacker, educator, and leader in embedded and connected device security. As the Vice President of Services, Larry drives strategic security initiatives across the software supply chain, helping product teams build resilient devices from the ground up. With over 15 years of hands-on penetration testing experience spanning IoT, healthcare, ICS/OT, and wireless technologies, he combines deep technical knowledge with real-world expertise. Larry is also a renowned SANS instructor and co-host of the long-running Paul’s Security Weekly podcast, shaping the next generation of security professionals.


