Full List of Required Documents for EN 18031 Compliance, RED Directive Cybersecurity Rules

EN 18031 series standards officially took full mandatory effect on August 1, 2025, alongside its three sub-standards. Starting from this date, all radio communication hardware newly launched and placed on the EU market must pass formal cybersecurity compliance assessment.

1. Clarify Correlation Between EN 18031 Sub-Standards and RED 3.3(d)(e)(f)

Misinformation about the matching logic between these standards spreads widely across the industry; the three sub-standards do not correspond to RED clauses one-to-one.

·EN 18031-1 & EN 18031-2 both cover RED 3.3(d) network protection and 3.3(e) personal data privacy protection, differentiated by device categories and data processing logic. EN 18031-1 boasts wider coverage and applies to any radio hardware capable of network connections. Note that the definition of "network" is not limited to internet access — Bluetooth, Zigbee, Z-Wave short-range communication all count. A Bluetooth speaker paired with a smartphone without internet access still falls under this standard’s scope. Pure one-way transmitters such as 433MHz garage door remotes and standalone wireless microphones carry no network connection functions and are fully exempt.

·EN 18031-3 covers RED 3.3(d), 3.3(e), plus additional 3.3(f) anti-fraud requirements. It applies to devices handling cryptocurrency or monetary transactions, including POS payment terminals, crypto hardware wallets, and wearables with built-in NFC payment modules. Ordinary consumer electronics rarely trigger this sub-standard.

Products may comply with one or multiple sub-standards simultaneously. A smartwatch with Wi-Fi connectivity, sensitive personal data storage, and NFC payment functionality must satisfy all three sets of standards, requiring three independent complete document packages.

  2. Cybersecurity Risk Assessment Report – Core Foundation of All Compliance Files

The risk assessment report serves as the cornerstone of the entire EN 18031 technical dossier, with all subsequent technical design documents compiled around its conclusions. Writers need to follow a fixed logical chain: Asset Identification → Threat Analysis → Security Countermeasure Deployment → Residual Risk Evaluation.

·Asset Identification: Compile a complete inventory of all product data, core functions and backend services, marking each asset with confidentiality, integrity and availability labels. Wi-Fi passwords are confidentiality assets, device firmware is an integrity asset, and emergency call functionality is classified as an availability asset. The more detailed the inventory, the better; notified bodies will demand supplementary files if any critical asset is omitted during audits.

·Threat Analysis: Map all potential attack paths targeting each listed asset. Common examples include brute-force cracking of Wi-Fi credentials and reverse engineering implantation of malicious firmware. Refer to the threat catalog attached to EN 18031, but avoid direct copy-paste; supplement unique attack surfaces based on your hardware’s actual circuit architecture.

·Security Mechanism Description: Attach specific protective solutions to every identified threat, with clear technical parameters and implementation logic. For firmware anti-tampering, specify secure boot paired with RSA 3072 signature verification, and note that debug interfaces are permanently disabled by factory default. Vague statements such as "data is encrypted" will be rejected outright by auditors.

·Residual Risk Evaluation: Certain threats cannot be completely eliminated — physical disassembly attacks on consumer electronics are a typical unavoidable risk. List residual risks truthfully with reasonable acceptance justifications; do not falsely claim "zero risk", as auditors understand perfect security is unattainable for commercial hardware.

  3. Technical Implementation Documents to Prove Security Controls Are Fully Deployed

·Security Architecture Design File: Draw a complete system security architecture diagram, clearly marking security domains, key storage locations, secure boot workflows and encrypted data transmission channels. If your hardware integrates dedicated secure chips or TEE trusted execution environments, highlight boundaries between secure and non-secure zones, as well as verification mechanisms activated when data crosses trust boundaries.

·Key Management Specification: Detail the full lifecycle of cryptographic keys, covering generation, storage, distribution and permanent destruction. Hardware encryption keys must be stored in chip eFuse zones or dedicated secure elements instead of plaintext Flash memory. Every finished unit must carry unique factory-programmed keys; shared universal keys across all product batches lead to full-series vulnerability if a single device is compromised, a point notified bodies audit with extreme strictness.

·Firmware Security Specification: Document secure boot logic, digital signature verification rules, anti-rollback protection and end-to-end OTA upgrade security protocols. Mandatory algorithms include RSA 3072 / ECC P-256 for signatures and SHA-256 for hash verification. Explain encrypted transmission channels for OTA packages, complete integrity checks, and automatic rollback mechanisms triggered by failed firmware updates.

·Communication Security Specification: List wireless encryption protocols, device authentication rules and session lifecycle management. Clearly state supported TLS versions and cipher suites, and prohibit deployment of TLS 1.1 or older protocols. Define session token validity periods and regular refresh mechanisms, as long-life unexpired tokens become a high-priority audit red flag. Draft a standalone section for debug interfaces; JTAG, UART and SWD ports must be locked at factory exit or protected by identity verification. Numerous hardware brands fail audits here due to exposed debug ports that allow attackers to dump full firmware data easily.

  4. Vulnerability Governance & Conformity Declaration Documents

·Vulnerability Management Process File: Outline end-to-end workflows covering vulnerability discovery, risk grading evaluation, patch development and official public notification. Set clear SLA repair timelines for high, medium and low-risk loopholes. List all vulnerability intelligence sources, including CVE database monitoring, end-user feedback and third-party penetration testing reports. If your firm does not employ full-time cybersecurity specialists, record details of outsourced security service providers and formal emergency response protocols.

·SBOM Software Bill of Materials: A complete inventory of all open-source components and third-party embedded libraries, including component names, version numbers and open-source license agreements. The SBOM is only a recommended document under the RED Directive and not a mandatory submission item for EN 18031 certification. Notified bodies may request copies during audits, but applicants will not face rejection for missing SBOM files. Still, maintaining an up-to-date SBOM drastically speeds up risk scope screening when security vulnerabilities emerge, so preparation is highly advised.

·EU Declaration of Conformity (DoC): Add official EN 18031 standard references to your RED DoC, clearly mark which subsets of RED 3.3(d)(e)(f) your product complies with, and write full standard codes with release years without omissions: EN 18031-1:2024, EN 18031-2:2024, EN 18031-3:2024.

  5. Common Costly Pitfalls During Actual Certification Submission

·Mandatory Notified Body Involvement Required: Online articles claiming manufacturers can complete self-declaration for RED 3.3(d) compliance are entirely false. The European Commission classifies all hardware subject to EN 18031 cybersecurity assessment as high-risk products, requiring formal certification issued exclusively by authorized notified bodies with zero exceptions. Third-party labs can conduct pre-compliance evaluation testing, yet only notified bodies hold authority for final document review and certificate issuance — make a clear distinction between these two roles.

·Mandatory Document Retention Term: All technical files must be stored for ten years starting from the date the last batch of your product enters the EU market, not from the day you cease sales. Retain risk assessment reports and vulnerability management records throughout your product’s full lifecycle; these files serve as core legal evidence if cybersecurity incidents arise.

·Severe Financial Penalties for Non-Compliance: Germany’s radio equipment supervision law imposes maximum fines of 100,000 Euros per violation, while France caps penalties at 300,000 Euros. The upcoming EU CRA framework introduces even harsher sanctions, with fines reaching 2% of a company’s global annual turnover for repeated serious violations — these penalties represent substantial financial losses for any hardware enterprise.

For full EN 18031 document sorting, pre-audit risk assessment and notified body filing coordination, reach out to BlueAsia compliance specialist Benson at +86 13534225140.