RED Cybersecurity Done - What Does the CRA Add? A Practical Guide for Wireless Product Makers
If your connected or IoT product is already compliant with the RED cybersecurity requirements - or you're in the middle of that work right now - you've probably started hearing about the Cyber Resilience Act (CRA) and wondering how the two fit together. The short answer: your EN 18031 work is genuinely reusable, but the CRA adds a whole layer of ongoing obligations that RED never touched. This guide maps the overlap and the gaps, and tells you what to do next.
TL;DR key points
- RED cybersecurity (via Delegated Regulation (EU) 2022/30) has been mandatory since 1 August 2025 for wireless/internet-connected radio equipment. The harmonised standards EN 18031-1/-2/-3:2024 were cited in the OJ in January 2025 — with restrictions.
- The CRA (Regulation (EU) 2024/2847) is horizontal: it covers all products with digital elements, not just radio equipment, and applies fully from 11 December 2027.
- The RED cybersecurity delegated regulation will be repealed on 11 December 2027, when the CRA takes over.
- Your EN 18031 technical work (secure defaults, no universal default passwords, attack-surface minimisation, secure updates, data protection) maps directly onto CRA Annex I Part I — it is not wasted.
- What the CRA adds that RED does not: SBOM, formal CVD policy, defined support period with free security updates, ENISA incident/vulnerability reporting (from 11 September 2026), and Annex VII technical documentation.
- This post is general information, not legal or compliance advice. For your specific product, consult a qualified expert.
Who this applies to
This guide is for manufacturers, importers, and EU-authorised representatives of wireless or connected products - anything that communicates via Wi-Fi, Bluetooth, cellular, Zigbee, LoRa, or any other radio interface and is placed on the EU market. That includes smart home devices, wearables, IoT sensors, industrial wireless gateways, connected toys, baby monitors, and payment terminals with radio interfaces.
If your product uses radio and connects to the internet, you are already in scope for RED cybersecurity. You will also be in scope for the CRA.
The two regimes side by side
| RED Cybersecurity (DA 2022/30) | Cyber Resilience Act (2024/2847) | |
|---|---|---|
| Legal basis | Directive 2014/53/EU + Delegated Reg. (EU) 2022/30 | Regulation (EU) 2024/2847 |
| Scope | Radio equipment only — internet-connected, data-processing, wearables, toys, payment devices | All products with digital elements — wired or wireless, hardware or software |
| Applies from | 1 August 2025 | 11 December 2027 (reporting from 11 Sep 2026) |
| Harmonised standards | EN 18031-1/-2/-3:2024 (OJ citation Jan 2025, with restrictions) | EN 40000 series in development; no OJ citation yet |
| Conformity route | Module A self-declaration (if EN 18031 applied in full, no restricted clauses triggered); otherwise Notified Body | Self-assessment for most products; Notified Body for Important Class I/II; EU certification for Critical |
| CE marking | Yes — must cover cybersecurity | Yes — replaces RED cybersecurity CE basis from Dec 2027 |
| Technical documentation | Art. 21 + Annex V of RED | Annex VII of CRA (broader, includes SBOM and vuln-handling evidence) |
| SBOM required? | No explicit requirement | Yes — machine-readable, at least top-level dependencies, kept current |
| CVD policy required? | No explicit requirement | Yes — publicly accessible contact point + coordinated disclosure policy |
| Support period / free updates | Not required | Yes — defined support period, free security updates throughout |
| Incident/vuln reporting to ENISA | No | Yes — via ENISA Single Reporting Platform from 11 Sep 2026 |
| Lifecycle obligations | Market-entry baseline only | Ongoing throughout the support period |
| Fate after Dec 2027 | Repealed | Becomes the sole cybersecurity framework for products with digital elements |
The timeline: 2025 -> 2027
RED cybersecurity requirements became mandatory on 1 August 2025 under Delegated Regulation (EU) 2022/30, activating Articles 3(3)(d), (e), and (f) of Directive 2014/53/EU. The deadline was originally set for August 2024 but was extended by one year because the harmonised standards were not yet available.
The three harmonised standards - EN 18031-1:2024, EN 18031-2:2024, and EN 18031-3:2024 - were cited in the Official Journal of the EU on 28 January 2025 via Implementing Decision (EU) 2025/138, with restrictions.
The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and will be fully applicable from 11 December 2027. Article 14 reporting obligations - covering actively exploited vulnerabilities and severe incidents notified via the ENISA Single Reporting Platform - apply earlier, from 11 September 2026.
Delegated Regulation (EU) 2022/30 is repealed with effect from 11 December 2027, the same date the CRA becomes fully applicable. From that date, products placed on the EU market must comply with the CRA; the RED cybersecurity route no longer applies to new placements.
What this means in practice: Radio equipment placed on the EU market between 1 August 2025 and 10 December 2027 is subject to RED cybersecurity requirements. Products placed on or after 11 December 2027 must comply with the CRA instead. Products placed before 11 December 2027 are generally subject to CRA requirements only if they are "substantially modified" from that date - though the Article 14 reporting obligation applies from 11 September 2026 regardless of when the product was placed on the market.
What carries over from RED to CRA
The good news: the technical security controls you implemented for EN 18031 are not wasted. The CRA's Annex I Part I essential requirements cover the same ground - and the draft CRA harmonised standard (the emerging EN 40000 series) is explicitly built on the EN 18031 series, augmented with additional controls.
Here is how the key EN 18031 control families map to CRA Annex I Part I:
| EN 18031 control area | CRA Annex I Part I requirement | Reusable? |
|---|---|---|
| ACM — Access control (no universal default passwords, enforced credential setup) | Protect against unauthorised access; secure-by-default configuration | ✅ Yes |
| AUM — Authentication mechanisms (strong auth, no skippable passwords) | Appropriate access control mechanisms including authentication | ✅ Yes |
| SUM — Secure update mechanism (signed firmware, integrity-verified OTA) | Authenticated, integrity-verified update mechanism | ✅ Yes |
| SCM — Secure communications (encrypted channels, TLS/IPsec) | Confidentiality and integrity of data; state-of-the-art cryptography | ✅ Yes |
| Attack-surface minimisation (disable unused services, least privilege) | Minimised attack surface; least privilege principle | ✅ Yes |
| Data minimisation / privacy by default (EN 18031-2) | Limit data collection to what is strictly necessary | ✅ Yes |
| VMP — Vulnerability management procedures (EN 18031-2/-3) | Vulnerability handling process (Annex I Part II) | ⚠️ Partial — CRA requires more formal CVD policy and ENISA reporting |
| Technical documentation (Art. 21 + Annex V RED) | Technical documentation (Annex VII CRA) | ⚠️ Partial — CRA Annex VII is broader; add SBOM and vuln-handling evidence |
| SBOM | Machine-readable SBOM (Annex I Part II) | ❌ Not required under RED — new obligation under CRA |
| Defined support period + free security updates | Defined support period; free security updates throughout | ❌ Not required under RED — new obligation under CRA |
| CVD policy (public contact point) | Publicly accessible CVD policy; contact point for vulnerability reports | ❌ Not required under RED — new obligation under CRA |
| ENISA incident/vuln reporting | Article 14 reporting via ENISA SRP (from 11 Sep 2026) | ❌ Not required under RED — new obligation under CRA |
What the CRA adds that RED does not
1. Scope: radio or not, it doesn't matter
RED cybersecurity only applies to radio equipment. The CRA applies to all products with digital elements - including wired connected devices, software, and the remote data processing solutions (cloud/SaaS components) that are integral to a product's function. If you make a product line that includes both wireless and wired variants, RED only covered the wireless ones. The CRA covers everything.
2. A defined support period with free security updates
The CRA requires manufacturers to declare a support period and provide free security updates throughout it. The regulation presumes a minimum of five years unless the product's intended use is shorter. You must clearly state the end-of-support date. RED has no equivalent obligation - once a device was on the market, there was no mandated update commitment.
3. An SBOM in a machine-readable format
CRA Annex I Part II requires manufacturers to identify and document all components in their product - including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format (CycloneDX or SPDX are the recognised options), covering at least top-level dependencies, kept current across the support period. The SBOM lives in your technical documentation and must be available to market surveillance authorities on request. RED has no SBOM requirement.
4. A formal CVD policy and public contact point
The CRA requires a publicly accessible coordinated vulnerability disclosure (CVD) policy and a contact address for vulnerability reports. This is not a best-practice recommendation - it is a legal obligation. Researchers, customers, and competitors need to be able to report vulnerabilities to you through a defined channel.
5. ENISA reporting from 11 September 2026
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to the ENISA Single Reporting Platform (SRP) and the relevant national CSIRT. The reporting timeline is tight: a 24-hour early warning, followed by a 72-hour notification, and a final report within 14 days of remediation. This obligation applies to all in-scope products already on the market - not just new placements after December 2027.
6. Annex VII technical documentation
The CRA's technical file (Annex VII) is broader than the RED Art. 21 file. It must include the cybersecurity risk assessment, the SBOM, evidence of vulnerability-handling processes, test results, and the EU Declaration of Conformity. Plan to extend your existing RED technical file rather than start from scratch - but do plan for the additions.
7. Horizontal application and lifecycle obligations
Perhaps the most important structural difference: RED cybersecurity is a market-entry baseline. Once the device is on the market, RED's job is done. The CRA is a lifecycle regulation - your obligations continue for the entire support period. Cybersecurity is no longer a one-time conformity exercise.
The EN 18031 presumption-of-conformity nuance you need to know
Before moving on, one important detail about EN 18031 that catches manufacturers out. The three standards were cited in the OJ with restrictions. If your product triggers a restricted clause, you do not get automatic presumption of conformity and a Notified Body assessment becomes mandatory.
The key restrictions to know:
- Password clauses (all three standards): If your implementation allows a user to skip setting a password or to operate the device without any password, clauses 6.2.5.1 and 6.2.5.2 do not confer presumption. You must enforce credential setup at first boot or use certificate-based bootstrapping.
- Parental/guardian access control (EN 18031-2): For childcare, toy, and wearable equipment covered by clauses 6.1.3-6.1.6, presumption is lost if parental access control is not ensured.
- Secure update for financial assets (EN 18031-3): Clause 6.3.2.4 lists four implementation categories for secure updates, but no single method alone is sufficient for financial assets. If this clause applies, presumption is not available and a Notified Body is required.
- Rationale and guidance sections: Text labelled "rationale" or "guidance" in EN 18031 does not confer presumption. Only normative clauses count.
If you self-declared under Module A on the basis of EN 18031 but your product allows users to skip password setup, your CE marking may not be valid. Review your implementation against the restricted clauses before your next market placement.
A practical "do this now" checklist
Here is a sequenced action list for manufacturers who have done (or are doing) RED EN 18031 work and need to prepare for the CRA:
Check that your EN 18031 implementation does not trigger any restricted clauses — especially the password clauses (6.2.5.1/6.2.5.2). If it does, engage a Notified Body now. Your RED technical file (Art. 21 + Annex V) should be complete and signed before any new market placement.
The Article 14 reporting obligation applies from 11 September 2026 to all in-scope products — including those already on the market. Register with the ENISA Single Reporting Platform and run an internal dry-run of your 24h / 72h / 14-day reporting workflow before the deadline. See the CRA reporting deadline guide for the detail.
Start generating machine-readable SBOMs (CycloneDX or SPDX) from your current build process. Cover at least top-level dependencies as the legal floor, but aim for transitive components — that's where most CVEs hide. The SBOM must stay current across the support period, so integrate it into your CI/CD pipeline now rather than retrofitting it in 2027.
Draft and publish a coordinated vulnerability disclosure policy. It needs to include a public contact address for vulnerability reports, your triage and remediation process, and your disclosure timeline. This is a CRA legal obligation, not a nice-to-have. It also feeds directly into your Article 14 reporting workflow.
Decide the support period for each product line and document it clearly — including the end-of-support date that must be communicated to users. The CRA presumes at least five years unless the product's intended use is shorter. Free security updates must be provided throughout this period.
Your RED Art. 21 technical file is a good starting point. Add the cybersecurity risk assessment (Article 13 CRA), the SBOM, vulnerability-handling evidence, and the EU Declaration of Conformity referencing Regulation (EU) 2024/2847. Annex VII requires a 10-year retention period. See the CRA technical documentation guide for what goes in each section.
Most wireless IoT products fall into the default (self-assessment) class. But some — including certain network devices, security products, and products listed in Annex III — are Important Class I or II and require Notified Body involvement. Use the CRA scope & class checker to confirm your classification.
Use this interactive tool to map your RED work to CRA gaps
The bigger picture: RED as the near-term baseline, CRA as the successor
The relationship between RED cybersecurity and the CRA is not adversarial - it is sequential. The European Commission designed the RED delegated regulation as a transitional measure to get cybersecurity baselines into the market while the CRA was being finalised. The CRA then takes over with a wider scope and deeper obligations.
For manufacturers of wireless products, this means:
- Now to December 2027: Comply with RED EN 18031. Keep your technical file current. Register for ENISA SRP reporting before September 2026.
- From December 2027: New market placements must comply with the CRA. Your EN 18031 technical work is the foundation - extend it, don't replace it.
- Products already on the market before December 2027 are generally not required to be retrofitted to full CRA compliance unless substantially modified. But the Article 14 reporting obligation applies from September 2026 regardless.
The CRA harmonised standards (the EN 40000 series) are still in development - public enquiry of the draft horizontal standard is expected from mid-2026. Until those standards are cited in the OJ, manufacturers will need to demonstrate conformity against the CRA text directly or use existing standards as supporting evidence. This is a real practical challenge, and it is worth monitoring closely.
Not legal advice. This post explains the regulatory framework in general terms. The correct compliance route for your specific product depends on its category, intended use, and technical architecture. For formal conformity assessment decisions, consult a qualified expert or Notified Body.
Stay on top of every development - standards citations, Commission guidance updates, and ENISA SRP onboarding - by subscribing to The CRA Brief at /subscribe. It's free, plain-English, and goes out whenever something material changes.
Related reading
CRA Technical Documentation: What Annex VII Requires and How to Build Your Technical File
A plain-English guide to the CRA technical file: what Annex VII requires, how it differs from Annex I, the 10-year retention rule, and how to build it now from artefacts you already have.
CRA Substantial Modification: When Does a Software Update Re-Trigger Your Conformity Assessment?
Not every software update restarts your CRA conformity work. Here's where the line sits, what the Commission's 2026 draft guidance says, and how to build a lightweight gate into your release process.
Inside the ENISA Single Reporting Platform: How CRA Vulnerability Reports Actually Flow
The ENISA Single Reporting Platform is the only channel for CRA vulnerability reports from 11 September 2026 - but it isn't live yet. Here's how it works and what to build now.