EN 18031 became mandatory on 1 August 2025, with three sub‑standards all effective simultaneously. From that date, all new wireless devices placed on the EU market must pass cybersecurity assessment. I’ve seen too many companies submit the old RED technical files – missing the security documents – resulting in immediate rejection by Notified Bodies.

1. Correct Mapping of Standards to RED Articles

·EN 18031 has three parts – and their mapping to RED 3.3(d)(e)(f) is not one‑to‑one – many online sources get this wrong.

·EN 18031‑1 and EN 18031‑2 both cover 3.3(d) (network protection) and 3.3(e) (privacy protection). The difference lies in device type and data processing. EN 18031‑1 applies broadly to any radio device that can connect to a network – and “network” here includes local short‑range like Bluetooth, Zigbee, Z‑Wave – not just the Internet. A Bluetooth speaker connecting to a phone (no Internet) still triggers EN 18031‑1. Pure one‑way transmitters like 433MHz garage remotes or wireless microphones that do not establish a network connection are indeed exempt.

·EN 18031‑3 covers 3.3(d), 3.3(e), plus 3.3(f) (fraud prevention). This applies to products involving virtual currency or money transfers – POS terminals, crypto hardware wallets, payment‑enabled wearables. Most consumer electronics won’t touch this.

·You may trigger one, two, or all three – e.g., a smartwatch with Wi‑Fi, sensitive personal data, and NFC payment – all three, requiring separate files for each.

  2. Security Risk Assessment – The Core Document

The security risk assessment is the foundation of the entire EN 18031 package – all subsequent technical implementation documents are built around it. Follow the logic chain: Assets → Threats → Security Mechanisms → Residual Risks.

·Asset identification: List all data, functions, and services in the product – assign confidentiality, integrity, and availability labels. Examples: Wi‑Fi password = confidentiality asset; firmware = integrity asset; emergency call function = availability asset. The more complete, the better – missing one will be caught during Notified Body audit.

·Threat analysis: For each asset, identify possible attack paths. Wi‑Fi password could be brute‑forced; firmware could be reverse‑engineered and maliciously updated. Reference the threat list in EN 18031’s annex, but don’t copy‑paste – add your product‑specific attack surfaces.

·Security mechanism description: For each threat, describe the countermeasure – its implementation and technical parameters. E.g., firmware anti‑tampering uses secure boot with RSA 3072 signature verification, debug ports disabled by default. Don’t just write “encrypted” – auditors won’t accept it.

·Residual risk assessment: Some threats can’t be fully eliminated – physical disassembly attacks on consumer electronics are inevitable. Be honest about residual risks and your acceptance rationale – don’t claim “zero risk” – auditors know that’s impossible.

  3. Technical Implementation Documents – Proving Controls Are Real

·Security architecture diagram: Draw system security zones, key storage locations, secure boot chain, encrypted communication channels. If you use a dedicated secure chip or TEE, clearly delineate the secure vs. non‑secure boundary and note cross‑trust‑zone validation mechanisms.

·Key management: Full lifecycle – generation, storage, distribution, destruction. Hardware keys must be stored in eFuse or secure element – never in plaintext in Flash. Each device must have a unique key – no shared default across all units. Notified Bodies enforce this strictly – one compromised shared key breaks the entire product line.

·Firmware security: Secure boot flow, signature verification, anti‑rollback, OTA update security. Signature algorithms: RSA 3072 or ECC P‑256 minimum; hash SHA‑256 or above. OTA must describe channel encryption, package integrity checks, and rollback logic on failure.

·Communication security: Wireless encryption protocols, authentication, session management. Specify TLS versions and cipher suites – do not use TLS 1.1 or below. Session token expiry and refresh intervals must be documented – long‑lived tokens are a red flag.

·Debug interface: JTAG, UART, SWD – must be disabled by default or require authentication. Many products fail because debug ports are left open, allowing an attacker to dump firmware.

  4. Vulnerability Management and Compliance Declarations

·Vulnerability management process: Discovery, assessment, remediation, notification. Define SLA – critical: how many days to fix, medium, low. List vulnerability intelligence sources – CVE monitoring, user feedback, third‑party penetration tests. If you don’t have an internal security team, specify outsourced security partners and response procedures.

·SBOM (Software Bill of Materials): List of open‑source components and third‑party libraries used – include name, version, licence. SBOM is currently recommended but not mandatory under RED; EN 18031 itself does not list it as a required submission. However, having one allows you to quickly self‑assess impact when vulnerabilities are disclosed – maintaining it is good practice, but it may not be audited.

·Declaration of Conformity: Update your RED DoC to reference EN 18031 and clearly indicate which of 3.3(d)(e)(f) are met. Use correct standard numbers with year: EN 18031‑1:2024, EN 18031‑2:2024, EN 18031‑3:2024 – do not omit the year.

  5. Practical Pitfalls

·Notified Body involvement is mandatory. Some online sources claim 3.3(d) can be self‑declared – this is wrong. The European Commission has made it clear that all EN 18031‑related 3.3(d)(e)(f) compliance falls under higher‑risk categories and must be reviewed and certified by a Notified Body – no exceptions. Third‑party labs can help with assessment testing, but only a Notified Body can issue the final certificate – know the roles.

·Document retention: Keep records for 10 years from the date the last unit was placed on the EU market – not “after discontinuation”. Risk assessments and vulnerability management files should be kept for the product’s entire lifecycle – they serve as evidence in case of future security incidents.

·Penalties are real: Germany’s radio equipment market surveillance law fines up to €100,000; France up to €300,000. Under the future CRA, penalties can reach 2% of global annual turnover – not small change.

For full support on EN 18031 documentation and assessment, contact BlueAsia Testing & Certification: 13534225140 (Benson)