EN 18031 is where the Radio Equipment Directive cybersecurity requirements turn into testable engineering work, and most failed assessments trace back to how a team read the standard rather than to missing encryption. The three parts, EN 18031-1, EN 18031-2 and EN 18031-3, define security mechanisms, decision trees and assessment criteria for internet-connected radio equipment, equipment that processes personal data, and equipment that moves money or virtual currency. This guide works through the mechanisms requirement by requirement, explains what the restrictions in the Official Journal citation mean for design choices, and shows how to build the technical documentation an assessor or market surveillance authority expects. It is written for product security engineers, compliance leads and test lab liaisons. The law itself (scope, timeline, penalties, conformity routes) is covered in the EU Radio Equipment Directive Cybersecurity Guide; this page goes deeper on the standards.
Key takeaways
- Three parts, one pattern. EN 18031-1 supports Article 3(3)(d) (network harm), EN 18031-2 supports Article 3(3)(e) (personal data and privacy) and EN 18031-3 supports Article 3(3)(f) (fraud); each repeats a common mechanism set and adds part-specific requirements.
- Applicability decisions are the real test. Every mechanism starts with an applicability requirement (ACM-1, AUM-1, SUM-1 and so on) and a decision tree; a weak "not applicable" justification is the commonest reason a file fails review.
- The citation carries restrictions. Commission Implementing Decision (EU) 2025/138 cited all three parts but withholds the presumption of conformity where a product lets the user choose not to set any password, for the rationale and guidance text, for some children's access control cases in Part 2 and for part of the secure update assessment criteria in Part 3.
- Design out the restrictions. The simplest way to keep the self-declaration route is to remove the "no password" option, implement parental controls fully, and meet the secure update criteria without relying on the restricted text.
- Evidence is engineering output. Interface inventories, asset lists, key lists and decision tree records double as product security documentation that the Cyber Resilience Act will also expect.
The three parts and what each adds
All three parts were published by CEN and CENELEC in 2024 and cited in the Official Journal of the EU on 30 January 2025 through Implementing Decision (EU) 2025/138, which amended Implementing Decision (EU) 2022/2191. Each part has the same skeleton: scope, terms, an "application of this document" clause, clause 6 requirements, an informative rationale annex, informative mapping annexes and Annex ZA linking the clauses to the Delegated Regulation. The difference is the asset each part protects and the extra mechanisms it adds.
| Part | RED article supported | Equipment in scope | Protected asset | Mechanisms beyond the common set |
|---|---|---|---|---|
| EN 18031-1:2024 | Article 3(3)(d): no harm to the network or misuse of network resources | Internet-connected radio equipment | Security assets and network assets | RLM resilience, NMM network monitoring, TCM traffic control |
| EN 18031-2:2024 | Article 3(3)(e): safeguards for personal data and privacy | Internet-connected equipment, childcare equipment, toys and wearables that process personal, traffic or location data | Privacy assets (personal information, privacy function configuration, privacy functions) | ACM-3 to ACM-6 children's access control, LGM logging, DLM deletion, UNM user notification, GEC-7 documentation of external sensing capabilities |
| EN 18031-3:2024 | Article 3(3)(f): protection against fraud | Internet-connected equipment that lets the holder transfer money, monetary value or virtual currency | Financial assets (financial data, financial function configuration, financial functions) | LGM logging, GEC-8 equipment integrity |
A single product often needs two or three parts at once. A smart speaker with a voice assistant and in-app purchases can fall under all three, and the same authentication or update mechanism is then assessed three times against three asset sets. Plan one engineering implementation and three applicability analyses, not three separate designs.
The asset model in practice
EN 18031-1 defines a security asset as sensitive or confidential security parameters plus security functions, and a network asset as sensitive or confidential network function configuration plus network functions. "Sensitive" means manipulation causes harm; "confidential" means disclosure causes harm. Parts 2 and 3 reuse the same split for privacy and financial assets. The practical output is an asset register per product with, for each item, its category, where it is stored, which interfaces can reach it and which mechanisms protect it. Typical entries are the Wi-Fi credentials, the device's cloud client certificate and private key, the firmware signing public key, the update server URL, the user's account token, microphone recordings, location history and stored payment tokens.
Common mechanisms, requirement by requirement
The table lists the clause 6 requirements of EN 18031-1 and what an assessor typically asks to see. Parts 2 and 3 use the same IDs for the common mechanisms (clause numbers shift in Part 3 because RLM, NMM and TCM are absent and LGM is inserted).
| Mechanism | Requirements | Evidence that usually satisfies the assessor |
|---|---|---|
| ACM access control | ACM-1 applicability, ACM-2 appropriate mechanisms | Matrix of entities (user, admin, cloud service, other devices) against assets and interfaces, with the enforcing component for each cell |
| AUM authentication | AUM-1 applicability (network and user interfaces), AUM-2 appropriate mechanisms, AUM-3 authenticator validation, AUM-4 changing authenticators, AUM-5 password strength, AUM-6 brute force protection | Authentication method per interface, password policy and how unique per-device credentials are generated, lockout or delay behaviour with test results |
| SUM secure update | SUM-1 applicability, SUM-2 secure updates, SUM-3 automated updates | Signing scheme, where the verification key lives, anti-rollback design, update delivery channel, default auto-update behaviour |
| SSM secure storage | SSM-1 applicability, SSM-2 integrity protection, SSM-3 confidentiality protection | Storage location of each asset, use of secure element, TPM or encrypted partition, tamper detection |
| SCM secure communication | SCM-1 applicability, SCM-2 integrity and authenticity, SCM-3 confidentiality, SCM-4 replay protection | Protocol list per interface (TLS version and cipher suites, Bluetooth pairing mode, Matter or Thread security), certificate validation behaviour |
| RLM resilience (Part 1) | RLM-1 applicability and appropriateness | How the device behaves under flooding or loss of connectivity, rate limits, watchdogs |
| NMM network monitoring (Part 1) | NMM-1 applicability and appropriateness | For network equipment such as routers: what traffic is monitored to detect attacks against the network |
| TCM traffic control (Part 1) | TCM-1 applicability and appropriateness | For equipment that forwards traffic: filtering rules and defaults |
| CCK confidential cryptographic keys | CCK-1 appropriate keys, CCK-2 key generation, CCK-3 no static default values for preinstalled keys | Key inventory, key lengths, entropy source, proof that factory-installed keys are unique per device |
| GEC general equipment capabilities | GEC-1 no publicly known exploitable vulnerabilities, GEC-2 limit exposed services, GEC-3 optional services configuration, GEC-4 interface documentation, GEC-5 no unnecessary external interfaces, GEC-6 input validation | SBOM and vulnerability scan at release, port scan results, list of debug interfaces and how they are disabled, fuzzing or input validation tests |
| CRY cryptography | CRY-1 best practice cryptography | Algorithm and key length list against a recognised catalogue, with no deprecated primitives |
Where engineering teams get caught
- GEC-1 at the moment of placing on the market: the requirement is about known exploitable vulnerabilities in the shipped software and hardware, so the assessor wants a dated scan or SBOM review close to release, not one from early development. The Hardware and Firmware SBOM Guide covers building that inventory.
- GEC-5 and debug ports: UART, JTAG and SWD headers left open on production boards are external interfaces. Document each and show it is disabled or locked. See the Debug Interfaces Security Guide.
- CCK-3 and factory provisioning: a key or certificate copied to every unit in the factory fails. Per-device keys generated on the device or injected by a provisioning system with per-unit records pass. The IoT Device Identity with TPM and DICE Guide covers the hardware options.
- AUM-4 and AUM-5 together: if the product ships with a unique per-device password printed on a label, document how it is generated and how the user changes it. A shared default password fails AUM-5 regardless of complexity.
- SCM on local interfaces: teams secure the cloud connection with TLS and forget the local HTTP configuration page or the unauthenticated Bluetooth GATT service used during setup.
Decision trees and "not applicable" justifications
Each applicability requirement has a decision tree with numbered decision nodes. Walking the tree for each asset and each interface ends in PASS, FAIL or NOT APPLICABLE, and the record of that walk is the core of the technical documentation. Test labs report that ACM-1 is the most consequential tree: marking access control not applicable removes the downstream ACM and AUM obligations, so an error there makes a product look more secure than it is.
ACM-1 allows three kinds of exception: the asset is intended for public access, a legal constraint applies, or the intended operating environment already restricts access to authorised entities. The environment exception is the one that fails most often. A justification that says "the device is used in the home" does not show that access is limited without relying on the product, because guests on the home Wi-Fi are rarely controlled. A justification that holds up describes the environment, why the device is placed there, which controls restrict each access route (physical and network separately) and what the user must do, in enough detail for an independent evaluator to reach the same conclusion.
| Justification quality | Example | Likely outcome |
|---|---|---|
| Weak | "Local API is not applicable because the product is used in a private home." | Rejected: home networks are shared with guests and other devices |
| Weak | "The Bluetooth service is only active for a short time." | Rejected without a defined window, physical trigger and what can be done in that window |
| Acceptable | "Pairing requires a physical button press on the device; the GATT write service is only exposed for 120 seconds afterwards and accepts only the onboarding exchange defined in section X." | Usually accepted with test evidence |
| Acceptable | "The equipment is sold only for installation in a regulated laboratory with access control required by regulation Y; installation instructions require a segregated network." | Accepted when the referenced requirement and instructions are in the file |
The Official Journal restrictions and how to design around them
Implementing Decision (EU) 2025/138 lists the three standards with notices that limit the presumption of conformity. The EU Radio Equipment Directive Cybersecurity Guide explains the effect on conformity assessment routes; the engineering response is below.
| Restriction (paraphrased from the Decision) | Parts | Design response that restores the presumption |
|---|---|---|
| The rationale and guidance sections do not give a presumption of conformity | All three | Treat rationale and guidance as background only; make sure every claim in the file rests on the normative requirement and its assessment criteria |
| No presumption where, in applying the authentication clauses, the user is allowed not to set and use any password | All three | Remove any "skip password" or "no password" option from setup flows, apps and local interfaces; enforce a unique per-device credential or a user-set password before the asset is reachable |
| No presumption for equipment covered by ACM-3 to ACM-6 (clauses 6.1.3 to 6.1.6) if parental or guardian access control is not ensured | EN 18031-2 | Implement parental or guardian controls fully for toys and childcare equipment, with defaults restricted until the guardian configures access |
| No presumption for part of the assessment criteria for secure updates | EN 18031-3 | Meet SUM-2 with a design that does not depend on the restricted criterion: signed updates verified on the device, anti-rollback, authenticated delivery |
Where a restriction applies and the design is not changed, the manufacturer loses the self-declaration route for that article and must use EU-type examination or full quality assurance with a notified body. The design change is usually cheaper.
Part 2 specifics: personal data, children and wearables
- ACM-3 and ACM-4 defaults: toys must by default restrict children's access to external content to authorised sources, and toys and childcare equipment must by default restrict third-party access to children's privacy functions and personal information to what the intended function needs.
- ACM-5 and ACM-6 guardian controls: an authorised entity, usually the parent or guardian, must be able to configure what the child can reach and what other entities can reach about the child.
- LGM logging: LGM-2 to LGM-4 cover persistent storage of log data, a minimum number of stored events and time information. Plan storage size and clock source early; devices without a reliable clock need a documented approach to timestamps.
- DLM deletion: users need a way to delete personal information held on the device, which affects factory reset design and flash wear levelling.
- UNM user notification: UNM-2 covers appropriate notification content, for example telling the user about changes that affect their privacy assets.
- GEC-7 sensing capabilities: document cameras, microphones, location and other sensors so users and assessors know what the device can capture.
Part 2 sits alongside GDPR rather than replacing it. Use the same data inventory for both, and see the ETSI EN 303 645 Consumer IoT Guide for the consumer IoT provisions that Annex C of each part maps against.
Part 3 specifics: financial assets
EN 18031-3 applies to internet-connected equipment that lets the holder or user transfer money, monetary value or virtual currency: payment-capable wearables, connected vending or charging equipment, smart home devices with stored payment methods, and hardware wallets with radio interfaces. Its asset register covers financial data, financial function configuration and financial functions. It adds LGM logging and GEC-8 equipment integrity. Because of the restriction on part of the secure update criteria, Part 3 products deserve the most conservative update design: a hardware root of trust, signature verification before installation, rollback protection and logged update events. Payment tokens and API credentials held on the device are non-human credentials; treat them with the same lifecycle discipline as any other machine secret, as described in the Device and IoT Identity Guide.
Building the evidence file: a phased approach
- Classify the product (week 1): decide which of Articles 3(3)(d), (e) and (f) apply and therefore which parts. Record the reasoning, including why a part does not apply.
- Inventory interfaces and assets (weeks 1 to 3): list every network and external interface (Wi-Fi, Bluetooth, Thread, cellular, USB, UART, JTAG, local web server, mobile app API), every exposed service and every asset per part. This feeds GEC-2, GEC-4 and GEC-5.
- Walk the decision trees (weeks 3 to 5): for each asset and interface, record the path through each decision node and the outcome. Write justifications for every NOT APPLICABLE as if an independent evaluator will challenge them.
- Close the gaps (weeks 5 to 10): fix FAIL outcomes in engineering, prioritising the restriction triggers (no-password options, guardian controls, update design).
- Test (weeks 8 to 12): port scans of each build, authentication brute-force tests, update tampering and rollback tests, TLS configuration scans, input fuzzing, and a release-time vulnerability scan of the SBOM for GEC-1.
- Pilot with a lab (weeks 10 to 12): run a pre-assessment with a test lab or notified body on one product before rolling the template out across the portfolio.
- Maintain: re-run applicability and GEC-1 whenever firmware, hardware or the cloud service changes. A change that alters an outcome needs a documented re-assessment; roll back the release if it introduces a FAIL that cannot be fixed before shipping.
Small versus large manufacturers
A small manufacturer with one product line can keep the evidence in a single structured document per product. A large portfolio benefits from a shared component library: one assessed update agent, one assessed TLS stack, one provisioning process, each with its own decision records that product files reference. That reuse is where most of the effort saving comes from, and it carries straight into Cyber Resilience Act technical documentation.
Measuring readiness
- Coverage: percentage of in-scope SKUs with a complete decision tree record for every applicable part.
- Justification quality: number of NOT APPLICABLE outcomes challenged by a lab or internal reviewer, and how many were overturned.
- Restriction exposure: count of SKUs still offering a no-password path or lacking guardian controls (target zero).
- GEC-1 freshness: days between the last vulnerability scan of the shipped image and the release date.
- Unique credentials: percentage of shipped units with per-device keys and passwords, verified from provisioning records.
Framework mapping
EN 18031 includes informative mapping annexes to EN IEC 62443-4-2:2019 (Annex B), ETSI EN 303 645 (Annex C) and SESIP (Annex D). For organisations that run NIST-based programmes, the following controls cover the same ground.
| EN 18031 mechanism | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| ACM, AUM | AC-3 Access Enforcement, IA-2 Identification and Authentication, IA-5 Authenticator Management | PR.AA-01 |
| SUM | SI-7 Software, Firmware, and Information Integrity, SI-2 Flaw Remediation | PR.PS-02 |
| SSM, CCK, CRY | SC-28 Protection of Information at Rest, SC-13 Cryptographic Protection | PR.AA-01 |
| SCM | SC-8 Transmission Confidentiality and Integrity | PR.DS-02 |
| GEC-2, GEC-3, GEC-5 | CM-7 Least Functionality, CM-6 Configuration Settings | PR.PS-01 |
| GEC-1 | RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation | PR.PS-02 |
| LGM | AU-2 Event Logging | DE.CM-09 |
For product development lifecycle requirements that EN 18031 does not cover, see the IEC 62443-4-1 and 4-2 Secure Product Development Guide.
Common failure patterns
- Applying Part 1 only: a fitness tracker assessed only against EN 18031-1, although it processes location and health data and needs Part 2.
- A hidden "skip" option: the device enforces a password, but the companion app offers "continue without password" for a local mode. That single path triggers the restriction.
- Relying on guidance text: the file quotes the rationale annex to justify a design, which the citation excludes from the presumption.
- Static keys in the factory image: one TLS client key or pairing secret shared across a production run, failing CCK-3.
- Stale vulnerability evidence: a GEC-1 scan run months before release, with library updates since then unassessed.
- Undocumented test interfaces: a manufacturing test mode reachable over Wi-Fi or a debug header left active, missing from the GEC-4 interface list.
After RED: the Cyber Resilience Act
Status on 13 November 2026: Delegated Regulation (EU) 2022/30 applies, EN 18031-1, -2 and -3 are cited with restrictions under Implementing Decision (EU) 2025/138, and Delegated Regulation (EU) 2026/339 repeals 2022/30 from 11 December 2027. This guide is general information, not legal advice.
The Commission states that Delegated Regulation (EU) 2022/30 entered into application in August 2025 and that its repeal by Delegated Regulation (EU) 2026/339 will take effect from 11 December 2027, when the Cyber Resilience Act's main obligations apply, to avoid overlapping requirements. Products in scope of both will move to CRA essential requirements and CRA harmonised standards. The EN 18031 work is not wasted: interface inventories, asset registers, update designs and unique credential provisioning are all expected under the CRA. See the EU Cyber Resilience Act Guide.
Practitioner checklist
- Record which RED articles and EN 18031 parts apply to each SKU, with reasons for any part excluded.
- Build an interface inventory that includes local, debug and manufacturing interfaces, and keep it in version control with the firmware.
- Maintain an asset register per part: security, network, privacy and financial assets with storage location and protecting mechanism.
- Walk every decision tree per asset and interface and keep the record; challenge every NOT APPLICABLE as an assessor would.
- Remove every path that lets a user avoid setting or using a password, in device, app and local web interfaces.
- Prove per-device uniqueness of preinstalled keys and passwords from provisioning records.
- Sign updates, verify them on the device, prevent rollback and log update events.
- For toys and childcare equipment, implement guardian controls and restrictive defaults before release.
- Run a vulnerability scan of the shipped image close to release and file the dated result for GEC-1.
- Reuse the evidence set for Cyber Resilience Act technical documentation.
Standards and references
- EUR-Lex: Commission Implementing Decision (EU) 2025/138 on harmonised standards for the RED cybersecurity requirements
- NEK: EN 18031-1:2024 preview, common security requirements for internet connected radio equipment
- NEK: EN 18031-2:2024 preview, radio equipment processing data
- NEK: EN 18031-3:2024 preview, radio equipment processing virtual money or monetary value
- European Commission: Radio Equipment Directive (RED)
- EUR-Lex: Commission Delegated Regulation (EU) 2026/339 repealing Delegated Regulation (EU) 2022/30
- Nemko: Cybersecurity under EN 18031, why access control exceptions need strong justification
Related NHI Mgmt Group resources: EU Radio Equipment Directive Cybersecurity Guide · ETSI EN 303 645 Consumer IoT Guide · EU Cyber Resilience Act Guide · Device and IoT Identity Guide. This guide summarises the EN 18031 harmonised standards and is not legal advice.