Finite StateFinite State
Finite StateFinite State
Get a DemoGet a Demo
Compliance & Regulations

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

Larry Pesce

VP of Services

February 15, 2026

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.

StandardSupportsEquipment covered
EN 18031-1:2024Article 3(3)(d), harm to the networkInternet connected radio equipment
EN 18031-2:2024Article 3(3)(e), personal data and privacyInternet connected, childcare, toys, and wearable radio equipment
EN 18031-3:2024Article 3(3)(f), protection from fraudInternet 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

#regulation
Larry Pesce

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.


Related Articles

An illustration of connected devices in dark teal against a black background with a hint of orange in the upper right — from left to right: a smart meter, a network switch, a laptop displaying a dashboard, a fitness tracker/smartwatch, a cable modem, a router, a rack-mounted server with multiple drive bays, a USB drive, another small router, a computer chip, an infusion pump, a smart speaker or lock, and a barcode scanner. The glowing, translucent rendering evokes cybersecurity and connected/IoT devices.

10 CRA Rules That Can Get Your Product Pulled From the EU Market

Conventional advice treats the Cyber Resilience Act as a 2027 problem with a fine attached. The obligation that binds first lands on September 11, 202...

Aug 25, 2026
Understanding The EU CRA's SBOM & Technical Documentation Requirements

EU Cyber Resilience Act (CRA) SBOM Requirements: Formats, Docs & The Upcoming Deadline

Ensure compliance with the EU Cyber Resilience Act. Learn how IoT manufacturers can streamline SBOM creation, updates, and documentation with expert t...

May 21, 2026
Router being scanned

The FCC's Waiver Extension for Routers Is the Right Call for Cybersecurity

Why patch status matters more than where it’s assembled—and what device makers should take from the policy reversal.

May 19, 2026

Ready to Level Up Your Security Knowledge?

Join thousands of security professionals learning from the best in the industry

Start Learning TodayStart Learning Today
Finite StateFinite State

Finite State is the Product Security Automation Platform that functions as an autonomous Product Security OS: design → verify → prove, grounded in what you ship.

Platform

Platform Overview
Ground Truth Inventory
Exploitability-Based Prioritization
Design-Time Architecture Security
Automated Evidence-Backed Compliance

Solutions

Device Manufacturers
Automotive
Medical Devices
Energy & Utilities
Government
Industrial

Resources

Blog
Resource Library
Webinars & Videos
Events
Documentation

Company

About Us
CareersHIRING
Press & News
Contact Sales
Media Inquiries
X

Privacy PolicyTerms of UseCustomer Terms and Conditions