How to Streamline RED Cybersecurity Compliance for IoT Devices
The EU Radio Equipment Directive now mandates cybersecurity compliance under EN 18031 for internet-connected devices. For IoT manufacturers, the path from requirement to conformity can be complex. This guide shows how to streamline every phase of the process.
April 6, 2026
Streamlining RED cybersecurity compliance means replacing ad-hoc, document-heavy processes with structured, repeatable workflows that reduce errors and accelerate time to market. For IoT manufacturers targeting the EU, EN 18031 is the key standard, and the right approach can cut compliance effort significantly.
Know which standards apply: EN 18031 has three parts mapping to RED Articles 3.3(d), 3.3(e), and 3.3(f). Identifying the right scope early prevents wasted work.
Start with asset identification: Security assets (functions and parameters) are the foundation. Every downstream requirement depends on them.
Use structured compliance tables: Replacing spreadsheets with purpose-built grids ensures consistency across sections and devices.
Automate decision trees and test plans: Guided workflows and auto-calculated verdicts eliminate manual tracking errors.
Generate your Declaration of Conformity from structured data: A single-click DoC export from verified compliance data is faster and more reliable than manual PDF assembly.
EN 18031 is a harmonised European standard published in three parts. Each part maps to a specific cybersecurity requirement activated by Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive (RED):
| EN 18031 Part | RED Article | Scope | Typical IoT Examples |
|---|---|---|---|
EN 18031-1 | Article 3.3(d) | Network security: protecting networks from harm caused by radio equipment | Routers, gateways, smart home hubs, industrial IoT controllers |
EN 18031-2 | Article 3.3(e) | Privacy and data protection: safeguarding personal data | Wearables, smart speakers, health monitors, connected cameras |
EN 18031-3 | Article 3.3(f) | Fraud prevention: preventing financial fraud via radio equipment | Payment terminals, connected POS devices, smart meters |
Most IoT devices will need at least EN 18031-1 (network security). Many will also require EN 18031-2 (privacy) if they process personal data. The first step in streamlining compliance is determining exactly which parts apply to your product, so you scope your documentation effort correctly from the start.
How standard field inheritance simplifies multi-part compliance
EN 18031 uses a hierarchical structure where the `standard` field cascades from sections to subsections to tables to columns. This means a single unified template can serve all three parts. When you select which standards your project requires, the system automatically filters to show only the relevant sections and tables. No manual tracking of which requirements belong to which part is needed.
The most effective way to streamline RED cybersecurity compliance is to follow a structured, phased approach. Each phase builds on the previous one, creating a clear path from initial scoping to final documentation.
Phase 1: Asset Identification
Every EN 18031 assessment begins with identifying your device's assets. EN 18031 defines five categories that must be catalogued:
Security functions: Device features that implement security measures (e.g., a firewall, TLS encryption, firmware update mechanism)
Security parameters: Data that defines how those functions behave - both Confidential Security Parameters (CSP) like private keys and passwords, and Sensitive Security Parameters (SSP) like configuration settings and access control lists
Network assets: Network interfaces, protocols, and data flows the device uses to communicate (e.g., Wi-Fi, Bluetooth, MQTT endpoints)
Privacy assets: Personal data types collected, stored, or transmitted by the device (applicable when EN 18031-2 is in scope)
Financial assets: Payment credentials, stored-value mechanisms, or transaction data (applicable when EN 18031-3 is in scope)
Getting asset identification right is critical. Every downstream compliance table, decision tree, and test plan references these assets. A streamlined tool auto-propagates asset identifiers into all dependent tables, so you enter them once and they flow everywhere they are needed.
Phase 2: Section-by-Section Compliance Documentation
EN 18031 organises requirements into sections covering Equipment Identification, Access Control Mechanisms, Vulnerability Handling, Cryptography, Software Update Mechanisms, Logging, Network Monitoring, and more. Each section contains structured compliance tables with specific columns for responses, justifications, and evidence references.
Streamlining this phase means using pre-structured tables that match the EN 18031 template exactly, with appropriate column types (text fields, select dropdowns, multi-select pick lists, and extra-info columns that split questions from additional details). This eliminates the guesswork of creating documentation formats from scratch.
Phase 3: Decision Tree Assessments
Many EN 18031 requirements are evaluated through decision trees: structured sequences of yes/no questions that lead to PASS, FAIL, or NOT_ASSESSED outcomes. A single device assessment can involve dozens of decision trees across multiple sections.
Streamlining decision trees means using a guided interface that tracks your position in each tree, records every answer, and automatically stores the final outcome in the corresponding compliance table row. No separate tracking spreadsheet or paper trail is needed.
Phase 4: Test Plan Generation and Verdicts
The EN 18031 test plan is a three-tier assessment:
Conceptual Assessment: Evaluates test items against decision tree results and expert justifications
Functional Sufficiency Assessment: Tests cases against defined assessment units to ensure coverage
Functional Completeness Assessment: Identifies gaps where documented test items are missing
The biggest time-saver in this phase is auto-calculated verdicts. Verdict conditions like "At least one PASS in column DT result" or "No FAIL entries present" are evaluated automatically against your actual data. Final verdicts are computed using pass/fail criteria masks, and incomplete data is flagged with a "-" indicator rather than risking an incorrect assessment.
Phase 5: Declaration of Conformity Generation
The final deliverable is the Declaration of Conformity (DoC) PDF required for EU market access. When all compliance data lives in a structured format, generating this document becomes a single-click operation. Equipment identification tables render vertically as key-value pairs, assessment tables render horizontally, and all pick lists, extra-info fields, and decision tree outcomes are formatted correctly without manual layout work.
For the detailed mechanics of each assessment phase, our risk assessment guide walks through the process step by step.
Even with the right process, certain bottlenecks can slow IoT compliance significantly. Here is where teams typically stall and how to fix it:
| Bottleneck | Root Cause | Streamlined Solution |
|---|---|---|
Unclear scope | Teams do not know which EN 18031 parts apply | Start with a project-level standard selection that auto-filters all downstream content |
Incomplete asset inventories | Security assets are identified ad-hoc and missed in downstream tables | Use structured asset tables with auto-propagation to all dependent sections |
Inconsistent documentation | Spreadsheets diverge across team members and product variants | Use a single-source-of-truth compliance platform with role-based access |
Decision tree tracking errors | Paper-based or ad-hoc tracking loses branching logic | Use guided decision tree interfaces that record every answer and outcome automatically |
Manual verdict calculation | Test plan verdicts computed by hand introduce arithmetic errors | Use auto-calculated verdicts with real-time condition checking |
Slow DoC generation | Assembling PDFs from scattered sources takes days | Generate DoC directly from structured compliance data in one click |
Multi-device duplication | Starting from scratch for each product variant | Clone and adapt compliance data across devices, focusing only on differences |
The pattern is clear: most bottlenecks stem from unstructured data and manual processes. Replacing these with structured workflows and automation removes the friction without requiring more staff or external consultants.
One often-overlooked bottleneck is re-assessment after software updates. See our article on maintaining RED compliance for software updates.
Use this checklist to assess your current compliance readiness and identify where streamlining will have the greatest impact:
Identify which EN 18031 parts (1, 2, 3) apply to each product in your portfolio
Create a complete inventory of security assets (functions and parameters) for each device
Map security functions to their associated security parameters with explicit traceability
Use compliance tables that match the EN 18031 template structure exactly
Complete all decision tree assessments with recorded outcomes linked to table rows
Run the three-tier test plan (Conceptual, Functional Sufficiency, Functional Completeness)
Verify that all verdict conditions are met before generating the Declaration of Conformity
Review the DoC PDF for completeness: all sections present, no empty tables unexplained, all pick lists and extra-info fields populated
For multi-device portfolios: identify shared compliance data that can be reused across product variants
Establish a review cycle: compliance documentation must be updated when firmware, security mechanisms, or device architecture changes
If more than three items on this list are currently handled via spreadsheets or unstructured documents, your compliance process has significant room for streamlining.
What is the RED Directive and why does it require cybersecurity compliance?
The Radio Equipment Directive (RED) is EU legislation governing radio equipment placed on the European market. Delegated Regulation (EU) 2022/30 activates cybersecurity requirements under Articles 3.3(d), 3.3(e), and 3.3(f), requiring manufacturers of internet-connected devices to demonstrate cybersecurity compliance through technical documentation aligned with harmonised standards like EN 18031.
How long does RED cybersecurity compliance typically take for an IoT device?
The timeline depends on device complexity, the number of applicable EN 18031 parts, and whether the team has done it before. A simple IoT sensor targeting only EN 18031-1 might take a few weeks with structured tooling. A complex gateway requiring all three parts could take several months using manual processes. Streamlined workflows with automation can reduce this by 40-60% compared to spreadsheet-based approaches.
Can I comply with EN 18031 without third-party testing?
EN 18031 is a harmonised standard that provides a presumption of conformity with the RED cybersecurity requirements. Manufacturers can use it for self-assessment and produce their own technical documentation and Declaration of Conformity. Third-party testing is not mandated by the standard itself, though some manufacturers choose it for additional assurance.
What documentation is required for EN 18031 compliance?
EN 18031 requires structured technical documentation covering: asset identification (security functions and parameters), compliance tables for each applicable section (access control, cryptography, vulnerability handling, etc.), decision tree assessment outcomes, a three-tier test plan with documented verdicts, and a formal Declaration of Conformity (DoC). All documentation must demonstrate traceability from identified assets through to final compliance outcomes.
Is EN 18031 the same as ETSI EN 303 645?
No. ETSI EN 303 645 is a consumer IoT cybersecurity baseline that focuses on high-level security provisions. EN 18031 is a more detailed harmonised standard specifically designed to provide presumption of conformity with the RED cybersecurity requirements (Articles 3.3(d), 3.3(e), 3.3(f)). EN 18031 requires more structured documentation, including decision trees and three-tier test plans, making it more comprehensive but also more demanding to complete.
Streamlining RED cybersecurity compliance for IoT devices is not about cutting corners. It is about replacing unstructured, error-prone processes with structured, repeatable workflows that produce the same high-quality documentation faster and more reliably.
The five-phase approach (asset identification, section documentation, decision trees, test plans, and DoC generation) provides a clear path from initial scoping to final conformity. Automation of decision trees and test plan verdicts eliminates the most common sources of delay and error. And structured data means your compliance documentation can be maintained and updated as products evolve, rather than rebuilt from scratch with every firmware release.
For IoT manufacturers targeting the EU market, the question is not whether to comply with EN 18031, but how efficiently you can get there. The answer lies in structured workflows and the right tooling.
RedComply is purpose-built for EN 18031 and RED cybersecurity compliance. The platform provides the structured workflows described in this article, from asset identification through to Declaration of Conformity generation, with automation at every phase.
Here is how to start streamlining your IoT compliance:
Create a project and select which EN 18031 parts apply to your device (1, 2, 3, or any combination)
Add your device and identify your security assets using structured compliance tables
Work through each section with pre-built tables matching the EN 18031 template exactly
Complete decision trees with guided interfaces that record every outcome automatically
Generate your test plan with auto-calculated verdicts across all three assessment tiers
Export your Declaration of Conformity as a structured PDF ready for regulatory review
Visit redcomply.com to see how the platform transforms RED cybersecurity compliance from a documentation burden into a structured, manageable workflow.