Since 1 August 2025, wireless products sold in the EU must meet cybersecurity essential requirements before they can carry the CE mark, and many manufacturers still treat this as a radio test rather than a security engineering obligation. The Radio Equipment Directive (RED, Directive 2014/53/EU) always contained cybersecurity requirements in Article 3(3)(d), (e) and (f), but they only became binding when Commission Delegated Regulation (EU) 2022/30 switched them on for defined product classes. This guide explains which products are in scope, what the three requirements mean in practice, how the EN 18031 harmonised standards and their restrictions change your conformity route, and how the regime hands over to the Cyber Resilience Act in December 2027. It is for product security, compliance and engineering teams at connected device manufacturers and importers.
Key takeaways
- The requirements are already mandatory. Delegated Regulation (EU) 2022/30 has applied since 1 August 2025, after Delegated Regulation (EU) 2023/2444 moved the original 1 August 2024 date to give standardisation bodies more time.
- Scope turns on radio plus internet. Article 3(3)(d) covers any radio equipment that can communicate over the internet itself; (e) adds personal data, childcare products, toys and wearables; (f) covers internet-connected equipment that can transfer money or virtual money.
- EN 18031 gives presumption of conformity only in part. Implementing Decision (EU) 2025/138 cited EN 18031-1, -2 and -3:2024 with restrictions, so a product that lets users skip a password, lacks parental controls or relies on the restricted secure update criteria cannot self-declare on the standard alone.
- Restrictions push you to a notified body. Where harmonised standards are not applied in full, RED Article 17 requires EU-type examination (Annex III) or full quality assurance (Annex IV) instead of internal production control.
- The regime is temporary but the work is not. Delegated Regulation (EU) 2026/339 repeals 2022/30 from 11 December 2027, when Cyber Resilience Act obligations apply; the security mechanisms you build now carry straight over.
Scope: who and what is covered
The RED applies to "radio equipment": products that intentionally emit or receive radio waves for communication or radiodetermination. Recital 8 of Delegated Regulation 2022/30 makes clear that once a product is in scope, all of its parts must comply, including non-radio functions such as a wired Ethernet port or a USB service interface on the same device. A purely wired product with no radio function is outside the RED (it falls under the Cyber Resilience Act from December 2027).
| Requirement | What the RED text protects | Equipment in scope under Delegated Regulation 2022/30 |
|---|---|---|
| Article 3(3)(d): network protection | Equipment does not harm the network or its functioning nor misuse network resources | Any radio equipment that can communicate itself over the internet, directly or via other equipment (Art. 1(1)) |
| Article 3(3)(e): personal data and privacy | Safeguards to protect the personal data and privacy of the user and subscriber | Internet-connected radio equipment, childcare equipment, toys under Directive 2009/48/EC and wearables, where they can process personal, traffic or location data (Art. 1(2)) |
| Article 3(3)(f): protection from fraud | Features that ensure protection from fraud | Internet-connected radio equipment that enables the holder or user to transfer money, monetary value or virtual money (Art. 1(3)) |
Exclusions
- All three requirements: do not apply to equipment also covered by the Medical Devices Regulation (EU) 2017/745 or the In Vitro Diagnostic Regulation (EU) 2017/746 (Art. 2(1)). Those regimes carry their own cybersecurity requirements. See the Medical Device Security Guide.
- Points (e) and (f) only: do not apply to equipment covered by Regulation (EU) 2018/1139 (civil aviation), Regulation (EU) 2019/2144 (motor vehicle type approval) or Directive (EU) 2019/520 (electronic road tolling) (Art. 2(2)). Point (d) network protection still applies to such equipment.
Economic operators
The manufacturer performs the conformity assessment, draws up the Annex V technical documentation and EU declaration of conformity, affixes the CE mark and keeps the documentation for 10 years (Art. 10). Importers and distributors must check that this has been done; a company selling a white-label device under its own brand takes on the manufacturer role.
Compliance is judged per unit placed on the market: a model already on sale before 1 August 2025 had to comply for every unit placed on the market after that date.
Key obligations
The RED states outcomes, not controls. The practical content comes from the EN 18031 series, developed by CEN and CENELEC under standardisation request M/536: EN 18031-1 for Article 3(3)(d), EN 18031-2 for (e) and EN 18031-3 for (f). Each defines security requirements built around assets (security assets, network assets, privacy assets and financial assets) and mechanisms that protect them. EN 18031-1 clause 6 sets out the mechanisms below; parts 2 and 3 reuse the same pattern for privacy and financial assets.
| EN 18031-1 mechanism | Requirement IDs | What an assessor looks for |
|---|---|---|
| ACM: access control | ACM-1, ACM-2 | Which assets need access control and whether the chosen mechanism restricts entities appropriately |
| AUM: authentication | AUM-1 to AUM-6 | Authentication on network interfaces, authenticator validation, ability to change authenticators, password strength (AUM-5), brute force protection (AUM-6) |
| SUM: secure update | SUM-1 to SUM-3 | An update mechanism exists where needed, updates are integrity and authenticity protected, automated updates where appropriate |
| SSM: secure storage | SSM-1 to SSM-3 | Integrity and confidentiality protection for stored security and network assets |
| SCM: secure communication | SCM-1 to SCM-4 | Integrity, authenticity, confidentiality and replay protection on communications carrying assets |
| RLM: resilience | RLM-1 | Mitigation of denial of service effects on the device and its network functions |
| NMM: network monitoring | NMM-1 | For network equipment such as routers, ability to monitor traffic and detect attacks |
| TCM: traffic control | TCM-1 | For network equipment, ability to control and filter traffic |
| CCK: confidential cryptographic keys | CCK-1 to CCK-3 | Adequate key strength, sound key generation, no static default values for preinstalled keys (CCK-3) |
| GEC: general equipment capabilities | GEC-1 to GEC-6 | No publicly known exploitable vulnerabilities at release (GEC-1), limited exposed services, documented interfaces, no unnecessary external interfaces, input validation |
| CRY: cryptography | CRY-1 | Best practice cryptography for the mechanisms above |
Each requirement is assessed with a decision tree. The manufacturer decides, per asset and interface, whether each mechanism applies and justifies the decision; if it applies, its appropriateness is assessed. Each path ends in PASS, FAIL or NOT APPLICABLE, and the verdict depends on whether the documented justifications hold up.
The restrictions in Implementing Decision (EU) 2025/138
The Commission cited the three standards in the Official Journal on 30 January 2025 (Implementing Decision (EU) 2025/138 of 28 January 2025, amending Implementing Decision (EU) 2022/2191). It attached restrictions, and these decide your conformity route more than any other single factor:
- All three parts: the "rationale" and "guidance" sections give no presumption of conformity. Only the normative requirements and assessment criteria count.
- All three parts: no presumption of conformity where, under clauses 6.2.5.1 and 6.2.5.2 (password requirements), the user may choose not to set or use a password. A device that offers a "skip" option on first-time setup falls outside the presumption.
- EN 18031-2: for the toy, childcare and similar classes in clauses 6.1.3 to 6.1.6, no presumption where parental or guardian access control is not ensured (clauses 6.1.3.4.2, 6.1.4.4.2, 6.1.5.4.2 and 6.1.6.4.2).
- EN 18031-3: no presumption for the secure update assessment criteria in clause 6.3.2.4, so equipment handling financial assets must show its update mechanism goes beyond the standard's criteria.
Where a restriction bites, the harmonised standard is not fully applied, and RED Article 17 requires either EU-type examination by a notified body followed by conformity to type (Annex III) or full quality assurance (Annex IV). Internal production control (Annex II, self-declaration) is only available when the cited standards are applied in full for the relevant requirement.
Timeline and current status
Status confirmed on EUR-Lex and the European Commission RED page on 24 October 2026. Dates may change through further delegated acts, so check the Official Journal before relying on them.
| Date | Event |
|---|---|
| 12 January 2022 | Delegated Regulation (EU) 2022/30 published (adopted 29 October 2021); in force 1 February 2022 with original application date 1 August 2024 |
| 2023 | Delegated Regulation (EU) 2023/2444 moves application to 1 August 2025 because harmonised standards needed more time |
| 10 December 2024 | Cyber Resilience Act (Regulation (EU) 2024/2847) enters into force |
| 30 January 2025 | Implementing Decision (EU) 2025/138 cites EN 18031-1, -2 and -3:2024 in the Official Journal, with restrictions |
| 1 August 2025 | Article 3(3)(d), (e) and (f) apply to in-scope radio equipment placed on the EU market |
| 16 February 2026 | Commission adopts Delegated Regulation (EU) 2026/339 repealing 2022/30 (published 29 April 2026, in force 19 May 2026) |
| 11 December 2027 | Repeal takes effect; main Cyber Resilience Act obligations apply, and cybersecurity of radio products is regulated under the CRA instead |
The Commission's stated reason for the repeal is to avoid overlapping requirements: the cybersecurity requirements move from the RED to the CRA. The CRA requirements are broader: vulnerability handling, an SBOM, security update support periods and reporting of actively exploited vulnerabilities. See the EU Cyber Resilience Act Guide.
The Commission notes that voluntary private "RED cyber certificates" are not a recognised means of proving compliance.
Enforcement and penalties
The RED is enforced nationally by market surveillance authorities under Regulation (EC) No 765/2008 (RED Article 39) and, more recently, the Market Surveillance Regulation (EU) 2019/1020.
- Non-compliant equipment (Art. 40): an authority that has reason to believe equipment presents a risk evaluates it and, if non-compliant, requires corrective action, withdrawal or recall within a reasonable period. If the operator does not act, the authority may prohibit, restrict, withdraw or recall the product nationally and notify other Member States and the Commission.
- Union safeguard (Art. 41): if a national measure is contested, the Commission decides by implementing act; a justified measure is then applied in all Member States.
- Compliant but risky equipment (Art. 42): a Member State can act even against compliant equipment that still presents a risk.
- Formal non-compliance (Art. 43): missing or wrongly affixed CE mark or notified body number, missing or incorrect EU declaration of conformity, or missing or incomplete technical documentation. Persistent failure leads to restriction, prohibition, withdrawal or recall.
- Penalties (Art. 46): Member States set penalties that must be "effective, proportionate and dissuasive", and may include criminal penalties for serious infringements. There is no single EU fine level; amounts vary by country.
The bigger practical exposure is a withdrawal order for a whole product line. Missing technical documentation is the easiest finding to make: Annex V requires the list of harmonised standards applied (or the solutions used instead) and the software and firmware versions that affect compliance.
What it means for AI agents and non-human identities
The RED cyber requirements are, in large part, rules about device identity and machine credentials. The non-human identity angle is direct:
- Default credentials: AUM requirements and the password restriction in 2025/138 effectively end shared default passwords and "skip" options. Use per-device unique credentials or force a change at first use. CCK-3 applies the same thinking to cryptographic keys: no static default values for preinstalled keys shared across a fleet. See the Device and IoT Identity Guide.
- Device certificates and keys: SSM and CCK cover where private keys and tokens live on the device. Hardware-backed storage (a secure element or TPM) is the cleanest answer to SSM-3 confidentiality for device identity keys.
- Update signing keys: SUM-2 requires authentic updates, which makes the manufacturer's firmware signing key one of its most sensitive NHI credentials. Protect it in an HSM with restricted, logged access.
- Cloud and support back ends: the delegated regulation assesses the device, but a device is only as safe as the service accounts that can reach it. In the Verkada camera breach, admin credentials on an exposed support server gave attackers access to customer cameras, a failure no device-side test would catch. The CRA brings remote data processing into product scope from December 2027.
- AI features and agents: devices that embed AI assistants or that can place orders on a user's behalf are likely to fall under 3(3)(f) if they can transfer money or virtual money. The agent's API tokens are financial assets under EN 18031-3 and need secure storage, secure communication and authentication. See the Identity for IoT Fleets Guide.
Compliance steps
- Classify the portfolio. For every product, record whether it has a radio, whether it can communicate over the internet directly or via a hub or phone, whether it processes personal, traffic or location data, whether it is a toy, childcare product or wearable, and whether it can transfer money. Record which exclusion, if any, applies (MDR, IVDR, aviation, vehicles, tolling).
- Map requirements to standards. Decide which of EN 18031-1, -2 and -3 apply, and list the assets per part: security, network, privacy and financial assets, with their interfaces.
- Check the restrictions first. If the product lets a user skip setting a password, lacks parental controls in a covered class, or handles financial assets, decide early whether to redesign (for example remove the skip option) or plan for a notified body. This is the single biggest schedule risk.
- Run a threat model and gap assessment. Work through each EN 18031 decision tree for each interface, writing the applicability justification as you go. These justifications become your technical documentation. See the Threat Modelling Guide.
- Close the gaps in engineering. Typical fixes: unique per-device credentials, brute force lockout, signed firmware, TLS on management channels, disabled debug interfaces, and a known-vulnerability scan of components before release (GEC-1). An SBOM makes GEC-1 repeatable. See the SBOM Guide.
- Test. Combine conceptual review, functional tests of each mechanism and security testing (fuzzing of exposed services, penetration testing). Pilot the evidence package on one product first.
- Choose the conformity route. Annex II self-declaration where the standards are fully applied; Annex III or IV with a notified body otherwise. Update the EU declaration of conformity to reference Delegated Regulation 2022/30 and the standards used.
- Control change. Treat firmware releases as potential compliance changes: a release that adds an interface or changes authentication needs reassessment against the affected requirements, and the documentation must list the software versions assessed. If a release breaks compliance, roll back to the last assessed version while you fix it.
- Plan the CRA transition. Build vulnerability handling, SBOM generation, support periods and exploited vulnerability reporting now, so the December 2027 switch is a documentation exercise rather than a redesign.
Decision guidance and measurement
| Situation | Recommended route | Trade-off |
|---|---|---|
| Simple device, enforced unique password, no payment function | Apply EN 18031 in full, self-declare under Annex II | Fastest; relies on solid internal evidence |
| Product keeps an optional password for usability | Remove the option, or notified body under Annex III | Redesign cost against certification time and fees |
| Payment or ordering capability | EN 18031-3 plus notified body for secure updates | Longest lead time; start early |
| Product line with frequent firmware releases | Annex IV full quality assurance | Higher set-up cost, lower per-release friction for large manufacturers |
Small manufacturers usually do best with Annex II plus a laboratory review; large ones benefit from a standard EN 18031 evidence template. Track these metrics:
- Coverage: percentage of in-scope products with a current EN 18031 assessment for the firmware version on sale.
- Restriction exposure: number of products relying on a notified body because of a 2025/138 restriction.
- Known vulnerabilities at release: count of known exploitable vulnerabilities in shipped components (target zero, per GEC-1).
- Default credential rate: products or device batches shipping with shared credentials or keys (target zero).
- Change control: share of firmware releases reviewed for compliance impact before shipping.
Framework mapping
| EN 18031 area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK risk addressed |
|---|---|---|---|
| AUM, CCK (authentication, keys) | IA-2, IA-5 | PR.AA-01 | T1078.001 Default Accounts |
| SUM (secure update) | SI-2, SI-7 | PR.PS-02 | T1195.002 Compromise Software Supply Chain |
| SSM, SCM (storage, communication) | SC-28, SC-8 | PR.DS-02 | Credential theft from device storage or traffic |
| GEC (exposure, known vulnerabilities) | CM-7, RA-5 | ID.RA-01 | T1190 Exploit Public-Facing Application |
| NMM, TCM (network equipment) | SI-4 (monitoring) | DE.CM-09 | Misuse of network resources |
For consumer products, ETSI EN 303 645 covers much of the same ground and many manufacturers reuse its evidence. See the ETSI EN 303 645 Consumer IoT Guide and the IoT Security Guide.
Common failure patterns
- Keeping the "skip password" option: a usability choice that removes the presumption of conformity under all three parts and silently forces a notified body route.
- Weak applicability justifications: marking mechanisms NOT APPLICABLE without a defensible reason. The decision tree verdict depends on the justification, so this is where assessments fail.
- Fleet-wide keys: the same TLS private key or API secret in every unit, which fails CCK-3 and turns one extracted device into a fleet compromise.
- Assessing hardware once, then shipping new firmware: documentation that lists an old software version no longer matches the product on sale.
Practitioner checklist
- Inventory every radio product and classify it against Articles 1 and 2 of Delegated Regulation 2022/30.
- Record which of EN 18031-1, -2 and -3 apply and the assets each protects.
- Check each product against the three restrictions in Implementing Decision (EU) 2025/138.
- Remove shared default passwords and preinstalled static keys; enforce unique credentials or change at first use.
- Sign firmware with an HSM-protected key and verify signatures on the device.
- Scan third-party components for known exploitable vulnerabilities before every release.
- Document applicability justifications for every decision tree and every interface.
- Select the Article 17 conformity route and update the EU declaration of conformity.
- Add compliance impact review to the firmware release process.
- Start the Cyber Resilience Act gap analysis for products still on sale after 11 December 2027.
Standards and references
- EUR-Lex: Directive 2014/53/EU (Radio Equipment Directive)
- EUR-Lex: Commission Delegated Regulation (EU) 2022/30
- EUR-Lex: Commission Delegated Regulation (EU) 2023/2444 (application date)
- EUR-Lex: Commission Implementing Decision (EU) 2025/138 (EN 18031 citation)
- EUR-Lex: Commission Delegated Regulation (EU) 2026/339 repealing Delegated Regulation (EU) 2022/30
- European Commission: Radio Equipment Directive (RED)
- NEK: EN 18031-1:2024 preview
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: EU Cyber Resilience Act Guide · IoT Security Guide · SBOM Guide · Device and IoT Identity Guide. This guide summarises the cybersecurity requirements of the EU Radio Equipment Directive as of October 2026 and is not legal advice.