Essential RED Cybersecurity Measures for IoT Devices

    The EU Radio Equipment Directive (RED) now mandates cybersecurity for internet-connected devices. EN 18031 defines the essential measures every IoT manufacturer must implement to achieve compliance and access the European market.

    March 17, 2026

    Key Takeaways: What IoT Manufacturers Must Know
    Essential RED cybersecurity measures for IoT devices under EN 18031 and the EU Radio Equipment Directive

    RED cybersecurity measures for IoT devices are a set of mandatory security requirements activated by Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive. These measures are defined in EN 18031 (parts 1, 2, and 3) and cover everything from access control and cryptography to vulnerability handling and secure software updates.

    • Three compliance pillars: EN 18031-1 covers network protection (Article 3.3(d)), EN 18031-2 covers privacy and data protection (Article 3.3(e)), and EN 18031-3 covers fraud prevention (Article 3.3(f)).

    • Security assets are the starting point: Every compliance assessment begins with identifying security functions and security parameters on your device.

    • Structured documentation is required: Manufacturers must produce detailed technical documentation covering asset inventories, compliance tables, decision tree outcomes, test plans, and a Declaration of Conformity (DoC).

    • Measures span the full device lifecycle: From secure boot and authentication to software updates and vulnerability disclosure, every phase must be addressed.

    • Compliance is mandatory for EU market access: Devices that fail to meet these requirements cannot carry the CE mark for radio equipment.

    The RED Directive and EN 18031: Why Cybersecurity Is Now Mandatory

    The Radio Equipment Directive (RED) has governed the EU market for radio equipment since 2014, covering electromagnetic compatibility, spectrum use, and safety. In 2022, the European Commission adopted Delegated Regulation (EU) 2022/30, which activated cybersecurity requirements under three articles:

    • Article 3.3(d): Radio equipment shall not harm the network or its functioning, nor misuse network resources.

    • Article 3.3(e): Radio equipment shall incorporate safeguards to ensure the protection of personal data and privacy.

    • Article 3.3(f): Radio equipment shall support certain features of protection from fraud.

    To demonstrate conformity with these articles, the European Commission designated EN 18031 as the harmonised standard. This means that manufacturers who follow EN 18031 benefit from a presumption of conformity with the RED cybersecurity requirements - the most practical compliance path available.

    Which devices are affected?

    The scope is broad. Any radio equipment that connects to the internet falls under Article 3.3(d). Devices that process personal data or connect to networks handling personal data are covered by Article 3.3(e). Equipment involved in monetary or virtual currency transfers must meet Article 3.3(f). In practice, this encompasses most IoT devices: smart home products, industrial gateways, wearables, connected sensors, automotive connectivity modules, and more.

    EN 18031 cybersecurity measures spanning access control, cryptography, vulnerability handling, and secure updates for IoT devices
    The Essential Cybersecurity Measures Under EN 18031

    EN 18031 organises cybersecurity requirements into well-defined domains. Each domain addresses a specific security objective, and together they form a comprehensive security posture for IoT devices. Here are the essential measures every manufacturer must implement:

    1. Equipment Identification

    Every device must be uniquely identifiable. This includes hardware identifiers, firmware versions, radio module details, and software component inventories. Proper identification is the foundation for traceability and incident response.

    2. Access Control and Authentication

    Devices must implement mechanisms to restrict access to authorised users and processes only. This includes password policies, multi-factor authentication where appropriate, role-based access control, session management, and protection against brute-force attacks. Default credentials must be unique per device or require change on first use.

    3. Cryptographic Implementations

    All cryptographic functions must use recognised, actively maintained algorithms and libraries. This covers encryption of data in transit (TLS/DTLS), encryption at rest, digital signatures for firmware verification, and secure key management. EN 18031 requires that cryptographic implementations follow established best practices - homegrown cryptography is explicitly discouraged.

    4. Secure Software Update Mechanisms

    Devices must support secure software updates throughout their lifecycle. Updates must be authenticated (digitally signed), integrity-verified, and delivered through secure channels. Anti-rollback mechanisms should prevent reverting to known-vulnerable firmware versions. The update process itself must not introduce new attack vectors.

    Maintaining compliance across software releases is an ongoing challenge. See our guide on ensuring RED compliance for software updates.

    5. Vulnerability Handling and Disclosure

    Manufacturers must establish processes for monitoring, identifying, and addressing security vulnerabilities in their products. This includes a coordinated vulnerability disclosure policy, timely security patch delivery, and clear communication channels for security researchers and users.

    6. Secure Storage and Data Protection

    Security parameters (passwords, cryptographic keys, tokens, access control configurations) must be stored securely. Confidential security parameters require both integrity and confidentiality protection. Sensitive security parameters require at least integrity protection. Plain-text storage of secrets is not acceptable.

    7. Logging and Monitoring

    Devices should maintain security event logs to support incident detection and forensic analysis. Log integrity must be protected, and logging must not expose sensitive security parameters.

    8. Network Security

    Devices must minimise their network attack surface: disable unnecessary services and ports, implement firewall rules where applicable, protect against denial-of-service conditions, and ensure that network communications are encrypted and authenticated.

    EN 18031 Parts Compared: Network, Privacy, and Fraud Prevention

    The three parts of EN 18031 share a common structure but target different security objectives. Understanding which parts apply to your device determines the scope of your compliance effort.

    EN 18031 three-part structure: network security, privacy protection, and fraud prevention mapped to RED Articles 3.3(d), 3.3(e), and 3.3(f)
    AspectEN 18031-1 (Network)EN 18031-2 (Privacy)EN 18031-3 (Fraud)

    RED Article

    3.3(d)

    3.3(e)

    3.3(f)

    Primary objective

    Protect networks from harm and resource misuse

    Protect personal data and privacy

    Prevent fraud involving monetary or virtual currency

    Asset focus

    Network assets: services, interfaces, communication channels

    Privacy assets: personal data stores, data flows, consent mechanisms

    Financial assets: payment credentials, transaction data, value stores

    Typical devices

    All internet-connected radio equipment

    Devices processing personal data or connected to networks with personal data

    Devices enabling monetary or virtual currency transfers

    Security functions

    Firewalls, network access control, traffic filtering

    Data encryption, anonymisation, consent management

    Transaction authentication, fraud detection, secure value transfer

    Shared requirements

    Access control, cryptography, secure updates, vulnerability handling

    Access control, cryptography, secure updates, vulnerability handling

    Access control, cryptography, secure updates, vulnerability handling

    Most IoT devices will need to comply with at least EN 18031-1 (network security). Devices handling personal data will additionally require EN 18031-2. Equipment involved in payments or virtual currency transfers must also meet EN 18031-3. Many devices will need compliance with two or all three parts simultaneously.

    Implementation Checklist: From Asset Identification to Declaration of Conformity
    Step-by-step compliance workflow from asset identification through decision trees to Declaration of Conformity

    Implementing RED cybersecurity measures is a structured process. Here is a practical checklist for IoT manufacturers:

    The first step is understanding what you need to protect. Our guide to EN 18031 assets breaks down the four asset categories.

    1. Determine applicable EN 18031 parts: Based on your device's functionality, identify whether parts 1, 2, 3, or a combination apply.

    2. Identify security assets: Catalogue all security functions (cryptographic libraries, authentication mechanisms, firewalls) and security parameters (keys, passwords, tokens, configuration data) on your device.

    3. Classify security parameters: Mark each parameter as sensitive (requires integrity protection) or confidential (requires both confidentiality and integrity protection).

    4. Complete compliance tables: For each EN 18031 section, document how your device meets the requirements - access control mechanisms, cryptographic implementations, update pathways, vulnerability handling processes.

    5. Navigate decision trees: Work through the structured yes/no assessments for each requirement to arrive at PASS, FAIL, or NOT_ASSESSED outcomes.

    6. Execute the three-tier test plan: Complete the Conceptual Assessment, Functional Sufficiency Assessment, and Functional Completeness Assessment.

    7. Generate the Declaration of Conformity (DoC): Compile all results into the structured document required for CE marking and EU market access.

    8. Establish ongoing processes: Set up vulnerability monitoring, coordinated disclosure, and update delivery channels for the device's lifecycle.

    Common pitfalls to avoid

    • Treating compliance as a one-time event instead of an ongoing lifecycle commitment

    • Using default or shared credentials across device units

    • Neglecting to document security parameters that are embedded at build time

    • Skipping the test plan tiers, which leads to incomplete compliance evidence

    • Ignoring standard field inheritance rules when working across multiple EN 18031 parts

    Frequently Asked Questions

    When did the RED cybersecurity requirements become mandatory?

    Delegated Regulation (EU) 2022/30 activated the cybersecurity requirements under Articles 3.3(d), 3.3(e), and 3.3(f) of the Radio Equipment Directive. These requirements became mandatory on 1 August 2025. Since that date, manufacturers must ensure compliance to place radio equipment on the EU market. EN 18031 provides the harmonised standard pathway to demonstrate conformity.

    Do all IoT devices need to comply with all three EN 18031 parts?

    No. The applicable parts depend on your device's functionality. EN 18031-1 (network security) applies to virtually all internet-connected devices. EN 18031-2 (privacy) applies when the device processes personal data. EN 18031-3 (fraud prevention) applies only to devices involved in monetary or virtual currency transfers. Many IoT devices will need parts 1 and 2, while payment-related devices may need all three.

    What is the relationship between EN 18031 and ETSI EN 303 645?

    ETSI EN 303 645 is a cybersecurity standard for consumer IoT devices, providing baseline security recommendations. EN 18031 is a harmonised standard under the RED Directive, providing a presumption of conformity with the legal cybersecurity requirements. EN 18031 is broader in scope, more detailed in its requirements, and directly linked to EU market access. Compliance with EN 303 645 alone does not satisfy RED cybersecurity obligations.

    Can a manufacturer self-declare conformity, or is third-party testing required?

    Under the RED Directive, manufacturers can use the internal production control procedure (Module A) for self-declaration when following a harmonised standard like EN 18031. If a manufacturer does not follow the harmonised standard, third-party assessment by a notified body may be required. Using EN 18031 and producing thorough technical documentation is the most efficient path to self-declaration.

    How does EN 18031 compliance relate to the Cyber Resilience Act (CRA)?

    The Cyber Resilience Act is a separate EU regulation targeting digital products more broadly. While RED and CRA have overlapping objectives, they are distinct legal frameworks. EN 18031 compliance addresses RED requirements specifically. However, manufacturers who build a strong security posture through EN 18031 compliance will be better positioned when CRA obligations take full effect, as many foundational security measures overlap.

    Conclusion: Cybersecurity Is Now a Market Access Requirement

    The essential RED cybersecurity measures for IoT devices are no longer optional. With EN 18031 established as the harmonised standard, manufacturers have a clear framework for demonstrating compliance with Articles 3.3(d), 3.3(e), and 3.3(f) of the Radio Equipment Directive.

    The measures span the entire device lifecycle: from secure design and asset identification through access control, cryptography, and vulnerability handling to ongoing software updates and coordinated disclosure. Each measure is documented through structured compliance tables, validated through decision trees and three-tier test plans, and compiled into a Declaration of Conformity.

    For product security managers and compliance engineers, the path forward is clear: identify which EN 18031 parts apply, catalogue your security assets, work through each compliance domain systematically, and produce the technical documentation that demonstrates conformity. The complexity is real, but with the right tools and structured workflows, compliance is achievable.

    Getting Started with RedComply

    RedComply is a cybersecurity compliance automation platform purpose-built for EN 18031 and the RED Directive. It transforms the complex documentation process into a guided, structured workflow - so your team can focus on engineering decisions instead of spreadsheet management.

    Here is how RedComply helps with every essential cybersecurity measure:

    • Structured asset identification: Catalogue security functions and parameters in purpose-built tables that auto-propagate to downstream compliance sections.

    • Guided decision trees: Navigate complex yes/no compliance assessments step by step, with outcomes automatically recorded in the correct table rows.

    • Auto-calculated test plans: Three-tier assessment workflow with automatic verdict computation based on pass/fail criteria masks.

    • Multi-standard filtering: Select EN 18031-1, -2, -3, or any combination - the platform shows only the sections and tables relevant to your scope.

    • AI-powered assistance: A built-in AI assistant that searches EN 18031, suggests appropriate responses, and flags inconsistencies across your documentation.

    • One-click DoC generation: Export your Declaration of Conformity as a structured PDF ready for regulatory review.

    Visit redcomply.com to start your EN 18031 compliance journey with the tools designed specifically for this standard.