RED Cybersecurity Delegated Act Compliance vs the CRA: What Applies to Your Radio Product, and When

Since 1 August 2025, any radio product that connects to the internet must meet the EU’s cybersecurity essential requirements. RED cybersecurity delegated act compliance is now enforceable, yet the Cyber Resilience Act (CRA) is already advancing to replace it.

That leaves engineers and compliance managers with a moving target: two overlapping frameworks, one product, and a repeal deadline in between. Get the mapping wrong and you either over-test or place non-compliant stock.

This guide shows which framework applies to your radio product today, how the three EN 18031 standards map to the RED’s requirements, and exactly what changes at each milestone through 11 December 2027, so you can build one technical file that survives the transition.

Which cybersecurity rules apply to your radio product today?

Today, the answer is the RED cybersecurity delegated act (RED DA). Commission Delegated Regulation (EU) 2022/30 switched on three long-dormant essential requirements in the Radio Equipment Directive (2014/53/EU).

Those requirements are Article 3(3), points (d), (e) and (f): network protection, protection of personal data and privacy, and protection from fraud. They apply whenever a radio product can communicate over the internet, directly or through other equipment.

The original deadline of 1 August 2024 was pushed back a year by Delegated Regulation (EU) 2023/2444. That extension is over. If your wireless product is on the EU market now, these radio equipment cybersecurity requirements already apply.

What counts as “internet-connected”?

The scope hinges on whether equipment “can communicate itself over the internet.” For a phone or router that is obvious. For a Bluetooth sensor that reaches the internet only through a paired smartphone app, it is not, and the RED does not settle it.

Treat that ambiguity as an interpretation risk in your risk analysis. Document why you concluded a product is, or is not, internet-connected. That reasoning is the first thing a market surveillance authority will probe.

What is the RED cybersecurity delegated act, and what does it require?

The delegated act does not spell out technical controls. It activates the essential requirements and leaves the “how” to harmonised standards. Meet a harmonised standard in full and you earn a presumption of conformity.

That presumption matters commercially. With it, you self-declare conformity under RED Annex II and place the product without a Notified Body. Lose it, and cost, lead time, and third-party assessment enter the picture.

EN 18031 helps by combining manufacturer requirements and test-lab assessment cases in one document, so design intent and verification sit side by side. Each requirement carries a code; for example, ACM-1 for an access-control rule.

Article 1(1) sets the scope for network protection: point (d) applies to “any radio equipment that can communicate itself over the internet, whether it communicates directly or via any other equipment.” Privacy pulls in wearables, toys, and childcare devices.

The harmonised route for all three requirements is the EN 18031 series. RED cybersecurity delegated act compliance therefore comes down to applying the right parts of EN 18031 to the right product, in full, and respecting the published restrictions.

Which of the three EN 18031 standards apply to your product?

The better question is not which one, but how many. Each part maps to one essential requirement, and a single product can trigger one, two, or all three.

The EN 18031 harmonised standard splits into three parts, each tied to a specific RED essential requirement:

• EN 18031-1:2024 — Article 3(3)(d), network protection, for internet-connected radio equipment (31 requirements).
• EN 18031-2:2024 — Article 3(3)(e), privacy and personal data, adding childcare, toy, and wearable radio equipment (40 requirements).
• EN 18031-3:2024 — Article 3(3)(f), protection from fraud, for equipment that transfers money, monetary value, or virtual currency (34 requirements).

You decide which parts apply through your product’s cybersecurity risk assessment, the same risk file that already covers safety and EMC. Get that mapping wrong and you either over-test or ship a gap.

Watch the overlap between the three parts

Twenty-eight requirement codes appear in all three parts with near-identical wording. Small differences, a single word, or “a path” versus “all paths” through a decision tree, can flip a verdict. Read each applicable part on its own.

How EN 18031 relates to ETSI EN 303 645

If you already tested to ETSI EN 303 645, you are not starting cold. Each EN 18031 part maps its requirements back to the EN 303 645 provisions, so prior baseline-IoT work carries over. It does not, however, replace a full EN 18031 assessment.

What does an EN 18031 risk assessment actually involve?

The standards are built around a risk assessment, not a checklist. You model threats with STRIDE, then work through decision trees to decide which requirements your product must meet.

EN 18031 groups its requirements into “mechanisms,” each with a three-letter code. The common ones you will meet include:

• ACM / AUM — access control and authentication.
• SUM / SSM / SCM — secure update, secure storage, and secure communication.
• CCK / CRY — confidential cryptographic keys and cryptography.
• RLM, NMM, TCM, LGM — resilience, network monitoring, traffic control, and logging, applied where relevant.

Not every mechanism applies to every product. The decision trees, driven by your threat model, tell you which requirements are in scope and which you can justify as not applicable.

This is why the three parts overlap yet differ. The same mechanism reappears in Parts 1, 2, and 3, but the asset it protects — the network, personal data, or funds — changes the wording and the verdict.

Do the EN 18031 restrictions change your conformity route?

Yes, and this is where teams get caught. When the series was cited in the Official Journal on 30 January 2025 (OJ L, 2025/138), the Commission attached restrictions that limit the presumption of conformity.

The clearest example is default passwords. Clauses 6.2.5.1 and 6.2.5.2 let a manufacturer allow a user to set no password. The restriction states that, if you implement that option, the essential requirements are not met, so the standard no longer covers you there.

Where a restriction removes your presumption of conformity, self-declaration under RED Annex II is off the table for that requirement. You then need a Notified Body to assess conformity under Annex III.

Default passwords are only one entry. The Official Journal lists further restrictions across the series, and each one you trigger narrows where the harmonised standard still buys you a presumption of conformity.

Plan for the Notified Body path early if any restriction is likely to apply to your design. Booking third-party assessment late is a common cause of missed launch dates.

So EN 18031 compliance is conditional, not automatic. Read the restrictions in the Official Journal before you assume the harmonised route gives you a clean self-declaration.

How does the CRA overlap with the RED delegated act?

The Cyber Resilience Act (Regulation (EU) 2024/2847) is horizontal: it covers almost all “products with digital elements,” not just radio. Most connected radio products sit inside both frameworks during the transition.

That is the core of the RED DA vs CRA question. Both demand secure-by-design engineering, vulnerability handling, and documentation. The CRA reaches further: its essential requirements sit in Annex I, its manufacturer duties in Article 13, and it adds lifecycle obligations the RED DA never imposed.

The biggest addition is reporting. From 11 September 2026, CRA Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT, a duty with no equivalent in the delegated act.

Products that also embed AI face a third overlapping regime; we set the AI Act against the CRA separately. Plan that evidence together rather than in silos.

Where the two frameworks differ in scope

Scope is the sharpest difference. The RED DA reaches only radio equipment that connects to the internet. The CRA reaches almost every product with digital elements, wired or wireless, plus the software sold with it.

The RED DA is also a point-in-time gate at market placement. The CRA imposes duties across the whole support period, security updates, coordinated vulnerability disclosure, and reporting — for as long as you sell and support the product.

When does the RED delegated act give way to the CRA?

Four dates define the transition, and each changes what you must be able to show:

• 30 January 2025 — EN 18031-1/-2/-3 cited in the Official Journal as the harmonised route, with restrictions.
• 1 August 2025 — RED cybersecurity delegated act compliance becomes mandatory for internet-connected radio equipment.
• 11 September 2026 — CRA Article 14 reporting obligations begin, layered on top of the RED DA.
• 11 December 2027 — the CRA applies in full and Delegated Regulation (EU) 2022/30 is repealed.

So the two regimes run in parallel for more than a year, from September 2026 to December 2027. Products placed on the market before 11 December 2027 still answer to the RED DA under continuing market surveillance.

The RED DA repeal by the CRA is now confirmed in direction. In early 2026 the Commission moved to repeal 2022/30, timed to the CRA’s full application. Radio cybersecurity does not disappear, it moves house, from the RED to the CRA.

What happens to products already on the market?

Placing on the market is a one-time event. A product lawfully placed under the RED DA before 11 December 2027 does not need re-approval under the CRA on that date, but it stays subject to market surveillance.

New or substantially modified products from 11 December 2027 fall under the CRA. Plan any launch that straddles the date against the framework that will apply when you actually place the unit.

Can one technical file cover both the RED DA and the CRA?

Largely, yes — and that is the efficient way to plan. The controls overlap heavily, so build the evidence once and map it twice rather than running two disconnected projects.

Anchor the file on a single cybersecurity risk assessment. Use EN 18031’s STRIDE-based method now; it feeds directly into the CRA’s Annex I risk analysis later. One assessment, two presumptions of conformity.

Maintain a software bill of materials from the start. The CRA expects an SBOM, and it sharpens the vulnerability handling that both regimes reward.

Stand up vulnerability handling and reporting before 11 September 2026. That is the CRA duty with the hardest deadline, and it has no RED DA process to inherit.

Keep one Declaration of Conformity that lists every applicable act. Today it cites the RED; from December 2027 it cites the CRA, while the underlying evidence barely changes.

The overlap is concrete. Most EN 18031 evidence transfers to the CRA’s Annex I with little rework:

• Access control and authentication map to Annex I secure-by-default and access-protection requirements.
• Secure update and storage map to the CRA duty to ship updates and protect data at rest.
• STRIDE threat modelling feeds the CRA’s mandatory risk assessment.
• Your EN 18031 test evidence supports the CRA technical documentation.

What you cannot copy across is the reporting duty. That process is new with the CRA and needs standing up on its own timeline.

Conclusion

The RED cybersecurity delegated act is mandatory now for internet-connected radio, so apply the right EN 18031 parts and mind the OJ restrictions.

Build one risk-based technical file so the same evidence serves both the RED DA and the CRA.

Stand up vulnerability reporting before 11 September 2026, the CRA duty with no RED DA equivalent.

On 11 December 2027 the RED DA gives way to the CRA — the teams that mapped both early will update a Declaration of Conformity, not restart.