CRA & Telekom/Funkgeräte: RED-DA-Abgrenzung

Funkgeräte-Hersteller zwischen zwei Cyber-Regimen: RED-DA seit August 2025, CRA ab 2027

Wer funkgebundene Produkte in den Verkehr bringt — WLAN-Gateways, Bluetooth-Sensoren, LTE/5G-Router, Smart-Home-Hubs, LPWAN-Module, drahtlose Kameras oder Wearables — hat seit dem 1. August 2025 die Cybersicherheitsanforderungen der RED-Delegierten-Verordnung (EU) 2022/30 am Hals. Diese aktiviert Art. 3.3 d/e/f der Funkanlagenrichtlinie: Netzschutz, Schutz personenbezogener Daten und Privatsphäre sowie Betrugsschutz. Und kaum ist das umgesetzt, steht mit dem Cyber Resilience Act (Verordnung (EU) 2024/2847) das nächste, deutlich breitere Regime vor der Tür. Genau hier entsteht der reale Schmerz dieser Branche: die Angst vor Doppel-Compliance, doppelter Dokumentation und doppelten Prüfkosten.

Die gute Nachricht vorweg — und sie ist der rote Faden dieses Beitrags: RED-DA und CRA sind kein Nebeneinander, das man zweimal komplett abarbeiten muss. Der CRA ist die horizontale, umfassendere Verordnung; für Produkte, die vom CRA erfasst sind, sollen dessen Anforderungen die entsprechenden RED-DA-Anforderungen ablösen, um genau diese Doppelregulierung zu vermeiden. Der Übergang ist allerdings gestaffelt, nicht schlagartig — und in dieser Übergangsphase muss produktbezogen und zeitpunktbezogen geprüft werden, welches Regime greift.

Für Funkgeräte-Hersteller heißt das konkret: Sie bauen jetzt (RED-DA) die technische Basis auf — Netzhärtung, Datenschutz-by-Design, Missbrauchsschutz nach EN 18031 — und diese Basis ist gleichzeitig das Fundament, auf dem der CRA später aufsetzt. Wer das clever plant, arbeitet einmal die Substanz ab und bedient zwei Regime. Wer es ignoriert, dokumentiert 2027 alles ein zweites Mal. Dieser Beitrag ist eine fachliche Einordnung, keine Rechtsberatung; die individuelle Betroffenheit ist im Einzelfall zu prüfen.

Typische Funk-Produkte, ihre wahrscheinliche Anhang-III-Klasse und der Konformitätspfad

Der CRA erfasst „Produkte mit digitalen Elementen" (PDE). Ein Funkgerät mit Software und (mittelbarer) Netzverbindung ist praktisch immer ein PDE. Die entscheidende Frage ist die Einstufung: Die große Mehrheit der Produkte fällt in die Standard-Kategorie und darf per Selbstbewertung (Modul A, interne Fertigungskontrolle) mit CE gekennzeichnet werden. Nur die in Anhang III als „wichtig" gelisteten Kategorien lösen strengere Pfade aus — und einige Funk-Produkte berühren genau diese Listen, weil sie Router-, VPN- oder Sicherheitsfunktionen mitbringen.

Die Grenzziehung ist im Einzelfall entscheidend und keine Formsache: Ob ein Gateway „nur" verbindet oder als Router bzw. Sicherheitskomponente wirkt, verschiebt es von der Selbstbewertung in die notifizierte Stelle. Die maßgeblichen technischen Beschreibungen der wichtigen/kritischen Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392 — dort gehört die Einstufung sauber hergeleitet und dokumentiert.

Branchennormen und Abgrenzung: RED-DA, CRA, NIS2, AI Act

Unter dem RED-DA konkretisiert die harmonisierte Normenreihe EN 18031-1/-2/-3 die Nachweise zu Netzschutz, Datenschutz und Betrugsschutz; für Consumer-IoT ist zusätzlich ETSI EN 303 645 der etablierte Anker. Diese Normen sind kein verlorener Aufwand: Härtung, sichere Update-Mechanismen, kein Default-Passwort, Angriffsflächenreduktion — dieselben Bausteine verlangt der CRA in Anhang I. Für den CRA entstehen parallel eigene harmonisierte Normen; wer bereits nach EN 18031 gebaut hat, hat den Großteil der Substanz bereits erbracht.

• RED-DA (VO 2022/30): greift für Funkgeräte seit 01.08.2025 auf die Cybersicherheits-Grundzüge (Art. 3.3 d/e/f).
• CRA: horizontal und breiter — Schwachstellen-Handling über den Support-Zeitraum, SBOM, CVD, Meldepflichten. Soll die entsprechenden RED-DA-Anforderungen für erfasste Produkte ablösen.
• NIS2: betrifft Betreiber wesentlicher/wichtiger Einrichtungen (z. B. TK-Netzbetreiber), nicht die Produkt-Herstellung. Ein Funkgeräte-Hersteller ist über NIS2 nur betroffen, wenn er selbst eine solche Einrichtung ist — ein getrennter Rechtsakt, der nicht mit dem CRA vermischt werden darf.
• AI Act: nur relevant, wenn KI-Funktionen an Bord sind (z. B. On-Device-Inferenz). Separates Regime, keine automatische Kopplung an die Funkzulassung.

SBOM und Lieferkette: der Embedded-OSS-Stack als gemeinsamer Nenner

Funkmodule und Gateways tragen die typischen Embedded-Stacks: ein Linux- oder RTOS-Kern, ein WLAN-/BLE-/Mobilfunk-Baseband-SDK des Chip-Herstellers, TLS-/Krypto-Bibliotheken (OpenSSL, mbedTLS, wolfSSL), ein Netzwerk-Stack, oft ein Web-UI-Framework — häufig in exakt der Version, die das SoC-SDK vor Jahren mitbrachte. Genau das ist das Kernrisiko: veraltete OSS-Komponenten (EOL-Kernel, ungepatchte TLS-Bibliothek), die nur im Baseband-SDK mitschwimmen und im eigenen Haus niemand mehr auf dem Radar hat.

Die Software Bill of Materials (SBOM) ist unter RED-DA wie CRA der gemeinsame Nenner und lohnt sich unabhängig von der Regime-Frage. Der CRA verlangt sie maschinenlesbar — in CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 (so auch BSI TR-03183-2 v2.1.0), mindestens auf Ebene der Top-Level-Abhängigkeiten, als Teil der technischen Dokumentation. Eine allgemeine Veröffentlichungspflicht gibt es nicht — die SBOM muss der Behörde bzw. notifizierten Stelle vorliegen, nicht dem Markt. Der Nutzen ist unmittelbar: Taucht morgen eine kritische Schwachstelle in der eingesetzten TLS-Bibliothek auf, beantwortet eine gepflegte SBOM in Minuten die Frage „Sind wir betroffen und in welchen Produktvarianten?" — statt in Wochen.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt aufgesetzt

Der CRA verlangt vom Hersteller Schwachstellen-Handling über den Support-Zeitraum (Leitwert mindestens 5 Jahre, orientiert an der erwarteten Produktlebensdauer), eine Policy zur koordinierten Offenlegung (CVD) und die Fähigkeit, aktiv ausgenutzte Schwachstellen und schwere Vorfälle fristgerecht zu melden. Diese Meldekaskade nach Art. 14 ist gestaffelt — die Fristen exakt zu kennen, ist Pflicht:

• 24 Stunden — Frühwarnung: ab Kenntnisnahme einer aktiv ausgenutzten Schwachstelle bzw. eines schweren Sicherheitsvorfalls.
• 72 Stunden — vollständige Meldung: inklusive der ergriffenen bzw. geplanten Korrektur- und Minderungsmaßnahmen.
• Abschlussbericht: bei einer aktiv ausgenutzten Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme; bei einem schweren Sicherheitsvorfall innerhalb von einem Monat nach der 72-Stunden-Meldung.

Gemeldet wird künftig über die ENISA Single Reporting Platform (SRP) — eine Einmalmeldung, die an das CSIRT der Hauptniederlassung und ENISA verteilt wird. Die Plattform ist zum 11.09.2026 bereitzustellen; Mitte 2026 ist sie noch nicht voll operativ, weshalb Hersteller ihre internen PSIRT-Prozesse jetzt schon aufsetzen sollten, statt auf das Werkzeug zu warten. Für einen Funkgeräte-Hersteller ohne dedizierten Security-Prozess ist das der praktisch anspruchsvollste Teil: 24 Stunden sind kein Puffer für eine Feierabend-Reaktion, sondern verlangen eine definierte Rufkette, Triage und einen Kontakt zur Meldestelle.

Fristen: was zuerst zählt

Zwei CRA-Daten sind für die Planung entscheidend — und sie liegen bewusst auseinander:

• 11.09.2026 — Melde- und Berichtspflichten (Art. 14): die erste harte Herstellerpflicht. Ab hier müssen aktiv ausgenutzte Schwachstellen und schwere Vorfälle nach der obigen Kaskade gemeldet werden.
• 11.12.2027 — volle Anwendbarkeit aller Produktanforderungen: Anhang I (Security-by-Design, SBOM, CVD), Konformitätsbewertung, CE, EU-Konformitätserklärung.

Zwischen beiden Terminen liegen rund 15 Monate. Wichtig für die Reihenfolge: Der PSIRT-/Meldeprozess muss zuerst stehen (2026), die volle Produktkonformität danach (2027). Für Funkgeräte-Hersteller kommt hinzu, dass die RED-DA-Pflichten bereits seit 08/2025 laufen — die technische Substanz aus EN 18031 ist also ohnehin schon aufzubauen und trägt direkt in die CRA-Anhang-I-Umsetzung hinein.

Durchgespieltes Beispiel: ein WLAN-Gateway-Hersteller

Ein mittelständischer Hersteller bringt ein WLAN-/Mobilfunk-Gateway mit Routing-Funktion in den Verkehr. Seit August 2025 erfüllt er die RED-DA-Anforderungen und weist Netzschutz, Datenschutz und Betrugsschutz nach EN 18031-1/-2/-3 nach — kein Default-Passwort, signierte Firmware-Updates, gehärtete Web-Oberfläche. Weil das Produkt eine Routing-Funktion hat, wäre es unter dem CRA voraussichtlich als wichtiges Produkt der Klasse I (Anhang III) einzuordnen; die Selbstbewertung bliebe nur bei voller Anwendung der einschlägigen harmonisierten Normen möglich, andernfalls käme eine notifizierte Stelle ins Spiel.

Der Hersteller zieht daraus drei parallele Arbeitsstränge: Erstens erzeugt er aus seinem Build eine CycloneDX-1.6-SBOM und entdeckt dabei eine ungepatchte TLS-Bibliothek aus dem SoC-SDK — die er härtet, bevor sie zum Meldefall wird. Zweitens richtet er bis 09/2026 einen PSIRT-Prozess mit 24-h-Rufkette und CVD-Kontakt ein. Drittens plant er die Anhang-I-Umsetzung und die Einstufungs-Herleitung so, dass alles zum 11.12.2027 dokumentiert und CE-fähig ist. Ergebnis: Er arbeitet die Substanz einmal ab und bedient beide Regime — statt 2027 alles ein zweites Mal zu dokumentieren.

Was Blackfort für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Funkgeräte- und Telekom-Hersteller genau durch diesen Übergang — von der RED-DA-Basis in die CRA-Konformität, ohne doppelte Arbeit:

• Betroffenheits- und Scope-Analyse: Ist Ihr Produkt PDE? Standard, Klasse I oder Klasse II? Wo greift noch RED-DA, wo schon CRA? Nachvollziehbar hergeleitet statt geraten.
• SBOM-Setup: maschinenlesbare Stückliste (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) aus Ihrem Build, inklusive EOL-/OSS-Risikoanalyse für den Embedded-Stack.
• PSIRT und CVD: Aufbau des Meldeprozesses passend zur Art.-14-Kaskade (24 h / 72 h / 14 Tage bzw. 1 Monat), rechtzeitig vor dem 11.09.2026.
• Risikobewertung und Threat-Modeling: die dokumentationspflichtige Risikoanalyse nach Art. 13 und Anhang I, methodisch sauber.
• Technische Dokumentation: Konformitätsunterlagen, die die 10-Jahres-Aufbewahrung und die Prüfung durch notifizierte Stellen tragen.

Prüfen Sie unverbindlich Ihre Ausgangslage mit dem Betroffenheits-Check, lesen Sie die Grundlagen auf der CRA-Übersichtsseite und die spezifischen Hinweise für kleine und mittlere Unternehmen — oder sprechen Sie uns direkt an über Kontakt. Diese Einordnung ersetzt keine Rechtsberatung im Einzelfall.