CRA & telecom/radio equipment: RED-DA delineation

Radio equipment makers between two cyber regimes: RED-DA since August 2025, CRA from 2027

Since 1 August 2025 the cybersecurity requirements of Delegated Regulation (EU) 2022/30 have applied to certain radio equipment, in particular equipment that can communicate over the internet - for example Wi-Fi gateways, LTE/5G routers, smart-home hubs, connected radio sensors, LPWAN modules, wireless cameras or wearables. The regulation activates Art. 3.3 d/e/f of the Radio Equipment Directive: network protection, protection of personal data and privacy, and fraud prevention. And no sooner is that done than the next, considerably broader regime looms with the Cyber Resilience Act (Regulation (EU) 2024/2847). This is exactly where the real pain of this sector sits: the fear of dual compliance, dual documentation and dual assessment cost.

The good news up front - and it is the thread running through this article: you do not have to work through RED-DA and CRA twice in full. The legal framework is settled: Delegated Regulation (EU) 2026/339 repeals Reg. 2022/30 with effect from 11 Dec 2027. From then on the CRA covers the requirements of Art. 3.3 d/e/f. Until then the RED requirements apply to these radio products, and since 11 Sep 2026 the reporting obligation under Art. 14 CRA applies in addition. For devices placed on the market up to 10 Dec 2027, RED market surveillance continues after the repeal.

For radio equipment makers this means concretely: you now build the technical basis (RED-DA) - network hardening, privacy-by-design, abuse prevention per EN 18031 - and that basis is at the same time the foundation on which the CRA later builds. Plan it early and you work through the shared substance once and add what the CRA requires on top. This article is a technical orientation, not legal advice; individual applicability must be assessed case by case.

Typical radio products, their likely Annex III class and the conformity path

The CRA covers "products with digital elements" (PDE). A radio device with software and (indirect) network connectivity is in principle a PDE. The core question is classification: products without an Annex III or Annex IV core function fall into the default category and may be CE-marked via self-assessment (Module A, internal control). Only the categories listed as "important" in Annex III trigger stricter paths - and some radio products fall exactly under them because their core function is routing, VPN or a security function (Article 7(1)).

The line matters in the individual case and is no formality: whether a gateway "merely" connects or has routing or a security function as its core function moves it from self-assessment to a notified body. The technical descriptions of the important/critical categories are set out in Implementing Regulation (EU) 2025/2392 - that is where the classification belongs, cleanly derived and documented.

Sector standards and delineation: RED-DA, CRA, NIS2, AI Act

Under the RED-DA the harmonised EN 18031-1/-2/-3 series, whose references were published with restrictions (Implementing Decision (EU) 2025/138), details the evidence for network protection, privacy and fraud prevention; for consumer IoT, ETSI EN 303 645 is the established anchor. This effort is not wasted: hardening, secure update mechanisms, no default password, attack-surface reduction - the CRA demands the very same building blocks in Annex I. Harmonised standards for the CRA have been requested (M/606) but were not yet published in the Official Journal on 9 October 2026. Products built to EN 18031 already cover important parts of Annex I Part I; vulnerability handling, the SBOM, the support period and reporting come on top. How we assess radio products against EN 18031 is described on the EN 18031 and Radio Equipment Directive page.

• RED-DA (Reg. 2022/30): applies since 01 Aug 2025 to certain radio equipment, in particular equipment that can communicate over the internet, for the cybersecurity essentials (Art. 3.3 d/e/f). Delegated Regulation (EU) 2026/339 repeals it with effect from 11 Dec 2027.
• CRA: horizontal and broader: vulnerability handling across the support period, SBOM, CVD, reporting duties. From 11 Dec 2027 it also covers the requirements of Art. 3.3 d/e/f; the reporting obligation under Art. 14 has applied since 11 Sep 2026.
• NIS2: concerns essential and important entities (e.g. telecom network operators), not product manufacturing. A radio equipment maker is affected by NIS2 only if it is itself such an entity, for example as a medium-sized or large manufacturer of electronic products (Annex II point 5) - a separate legal act that must not be conflated with the CRA.
• AI Act: applies in addition as soon as an AI system is built in (e.g. on-device inference); the scope of duties depends on the risk level. A separate regime, not automatically coupled to radio approval.

SBOM and supply chain: the embedded OSS stack

Radio modules and gateways contain the typical embedded stacks: a Linux or RTOS kernel, the chip vendor's Wi-Fi/BLE/cellular baseband SDK, TLS/crypto libraries (OpenSSL, mbedTLS, wolfSSL), a network stack, possibly a web-UI framework. Check whether these components still run in the version the SoC SDK shipped years ago. That is the core risk: outdated OSS components (EOL kernel, unpatched TLS library) that ride along inside the baseband SDK and that nobody in-house still tracks.

Only the CRA requires the SBOM; it already pays off today for vulnerability handling. The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. There is no general publication duty - the SBOM must be provided to market surveillance on reasoned request. The benefit is immediate: if a critical vulnerability surfaces tomorrow in the TLS library you use, a maintained SBOM answers "are we affected, and in which product variants?" in minutes rather than weeks.

Reporting capability and PSIRT: the Art. 14 cascade set up correctly

The CRA requires the manufacturer to handle vulnerabilities across the support period (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)), maintain a coordinated vulnerability disclosure (CVD) policy, and be able to report actively exploited vulnerabilities and severe incidents on time. This reporting cascade under Art. 14 is staggered - knowing the deadlines exactly is mandatory:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• Final report: for an actively exploited vulnerability within 14 days after a corrective or mitigating measure becomes available; for a severe incident within one month after the 72-hour notification.

Reporting runs via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. Manufacturers should stand up and maintain their internal PSIRT processes independently of the tool. For a radio equipment maker without a dedicated security process this is the practically hardest part: 24 hours demand a defined escalation chain, triage and a contact to the reporting point.

Deadlines: what counts first

Two CRA dates shape the planning - and they deliberately sit apart:

• 11 Sep 2026 - reporting obligations (Art. 14): the first hard manufacturer duty. Since then, actively exploited vulnerabilities and severe incidents must be reported per the cascade above.
• 11 Dec 2027 - full applicability of all product requirements: Annex I (security-by-design, SBOM, CVD), conformity assessment, CE, EU declaration of conformity.

Roughly 15 months lie between the two dates. Key for sequencing: the PSIRT/reporting process must already stand (mandatory since September 2026), full product conformity follows after (by 11 December 2027). For radio equipment makers there is the added fact that the RED-DA duties have applied since 08/2025 and remain in force until Reg. 2022/30 is repealed with effect from 11 Dec 2027. The technical substance from EN 18031 has to be built anyway and feeds directly into the CRA Annex I implementation.

A worked example: a Wi-Fi gateway maker

A mid-sized manufacturer places a Wi-Fi/cellular gateway with routing function on the market. Since August 2025 it meets the RED-DA requirements and demonstrates network protection, privacy and fraud prevention per EN 18031-1/-2/-3 - no default password, signed firmware updates, a hardened web interface. Because routing is the product's core function, under the CRA it would likely be classified as an important product of Class I (Annex III); self-assessment would remain possible only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”), otherwise a notified body would come into play (Module B+C or H).

The maker draws three parallel workstreams from this: first, it generates a CycloneDX 1.6 SBOM from its build and thereby discovers an unpatched TLS library from the SoC SDK - which it updates before it becomes a reporting case. Second, it immediately stands up a PSIRT process with an escalation chain for the early warning (without undue delay, within 24 hours at the latest) and a CVD contact, as the reporting duty has applied since 09/2026. Third, it plans the Annex I implementation, the classification rationale and the conformity assessment so that everything is documented by 11 Dec 2027. The result: the technical substance from EN 18031 feeds into the CRA implementation; SBOM, vulnerability handling and reporting come on top.

What Blackfort does for you

Blackfort Technology accompanies radio equipment and telecom manufacturers through this transition - from the RED-DA basis to CRA implementation, with the aim of not doing anything twice:

• Applicability and scope analysis: a technical assessment of whether your product is a PDE, whether it is default, Class I or Class II, which RED requirements apply until 10 Dec 2027 and which CRA duties already apply today. Traceably derived, for review by your legal department.
• SBOM setup: a machine-readable bill of materials, for example in CycloneDX or SPDX, from your build, including EOL/OSS risk analysis for the embedded stack.
• PSIRT and CVD: building the reporting process to match the Art. 14 cascade (early warning, notification, final report after 14 days or 1 month), immediately, as the duty has applied since 11 Sep 2026.
• Risk assessment and threat modeling: the documentation-required risk analysis under Art. 13 and Annex I, methodically sound.
• Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)).

Assess your starting position free of charge with the applicability check, read the fundamentals on the CRA overview page and the specific notes for small and medium-sized enterprises - or talk to us directly via contact. This orientation does not replace legal advice in the individual case.