CRA & telecom/radio equipment: RED-DA delineation

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

Anyone placing radio-connected products on the market — Wi-Fi gateways, Bluetooth sensors, LTE/5G routers, smart-home hubs, LPWAN modules, wireless cameras or wearables — has been carrying the cybersecurity requirements of the RED Delegated Act (Reg. (EU) 2022/30) since 1 August 2025. It 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: RED-DA and CRA are not two parallel tracks you have to run in full twice. The CRA is the horizontal, broader regulation; for products covered by the CRA, its requirements are intended to supersede the corresponding RED-DA requirements, precisely to avoid this dual regulation. The transition, however, is staggered rather than abrupt — and during it you must assess, product by product and point in time, which regime governs.

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 cleverly and you work the substance once and serve two regimes. Ignore it and you document everything a second time in 2027. 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 practically always a PDE. The decisive question is classification: the vast majority of products fall into the default category and may be CE-marked via self-assessment (Module A, internal production control). Only the categories listed as "important" in Annex III trigger stricter paths — and some radio products touch exactly those lists because they carry router, VPN or security functions.

The line is decisive in the individual case and no formality: whether a gateway "merely" connects or acts as a router or security component moves it from self-assessment into a notified body. The governing 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 standard series EN 18031-1/-2/-3 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. Dedicated harmonised CRA standards are emerging in parallel; whoever already built to EN 18031 has delivered most of the substance.

• RED-DA (Reg. 2022/30): applies to radio equipment since 01 Aug 2025 for the cybersecurity essentials (Art. 3.3 d/e/f).
• CRA: horizontal and broader — vulnerability handling across the support period, SBOM, CVD, reporting duties. Intended to supersede the corresponding RED-DA requirements for covered products.
• NIS2: concerns operators of essential/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 — a separate legal act that must not be conflated with the CRA.
• AI Act: relevant only if AI functions are on board (e.g. on-device inference). A separate regime, not automatically coupled to radio approval.

SBOM and supply chain: the embedded OSS stack as the common denominator

Radio modules and gateways carry 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, often a web-UI framework — frequently in exactly 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.

The Software Bill of Materials (SBOM) is the common denominator under both RED-DA and CRA and pays off regardless of the regime question. The CRA requires it machine-readable — in CycloneDX version 1.6 or later or SPDX version 3.0.1 or later (in line with BSI TR-03183-2 v2.1.0), at least at the level of top-level dependencies, as part of the technical documentation. There is no general publication duty — the SBOM must be available to the authority or notified body, not to the market. 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 (guideline value at least 5 years, tied to the expected product lifetime), 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: from becoming aware of an actively exploited vulnerability or a severe security incident.
• 72 hours — full notification: including the corrective and mitigating measures taken or planned.
• Final report: for an actively exploited vulnerability within 14 days after a corrective measure becomes available; for a severe security incident within one month after the 72-hour notification.

Reporting will run via the ENISA Single Reporting Platform (SRP) — a single submission distributed to the CSIRT of the main establishment and to ENISA. The platform is to be provided by 11 Sep 2026; in mid-2026 it is not yet fully operational, which is why manufacturers should stand up their internal PSIRT processes now rather than wait for the tool. For a radio equipment maker without a dedicated security process this is the practically hardest part: 24 hours is no buffer for an after-hours reaction, it demands a defined escalation chain, triage and a contact to the reporting point.

Deadlines: what counts first

Two CRA dates matter for planning — and they deliberately sit apart:

• 11 Sep 2026 — reporting obligations (Art. 14): the first hard manufacturer duty. From here, 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 stand first (2026), full product conformity after (2027). For radio equipment makers there is the added fact that the RED-DA duties have been running since 08/2025 — so the technical substance from EN 18031 is being 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 the product has a routing 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 the relevant harmonised standards, otherwise a notified body would come into play.

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 hardens before it becomes a reporting case. Second, it stands up a PSIRT process with a 24-hour escalation chain and CVD contact by 09/2026. Third, it plans the Annex I implementation and the classification rationale so that everything is documented and CE-ready by 11 Dec 2027. The result: it works the substance once and serves both regimes — instead of documenting everything a second time in 2027.

What Blackfort does for you

Blackfort Technology UG (haftungsbeschränkt) accompanies radio equipment and telecom manufacturers through exactly this transition — from the RED-DA basis into CRA conformity, without duplicated effort:

• Applicability and scope analysis: Is your product a PDE? Default, Class I or Class II? Where does RED-DA still govern, where does the CRA already apply? Traceably derived rather than guessed.
• SBOM setup: a machine-readable bill of materials (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) 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 (24 h / 72 h / 14 days or 1 month), in good time before 11 Sep 2026.
• Risk assessment and threat modeling: the documentation-required risk analysis under Art. 13 and Annex I, methodically sound.
• Technical documentation: conformity records that carry the 10-year retention and review by notified bodies.

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.