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

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

Für bestimmte Funkanlagen, vor allem solche, die über das Internet kommunizieren können, gelten seit dem 1. August 2025 die Cybersicherheitsanforderungen der Delegierten Verordnung (EU) 2022/30 - das betrifft etwa WLAN-Gateways, LTE/5G-Router, Smart-Home-Hubs, vernetzte Funk-Sensoren, LPWAN-Module, drahtlose Kameras oder Wearables. Die Verordnung 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 müssen Sie nicht zweimal komplett abarbeiten. Der Rechtsrahmen dafür steht fest: Die Delegierte Verordnung (EU) 2026/339 hebt die VO 2022/30 mit Wirkung vom 11.12.2027 auf. Ab dann deckt der CRA die Anforderungen nach Art. 3.3 d/e/f ab. Bis dahin gelten für diese Funkprodukte die RED-Anforderungen, seit dem 11.09.2026 zusätzlich die Meldepflicht nach Art. 14 CRA. Für Geräte, die bis zum 10.12.2027 in Verkehr gebracht werden, bleibt die Marktüberwachung nach RED auch nach der Aufhebung bestehen.

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 früh plant, arbeitet die gemeinsame Substanz einmal ab und ergänzt für den CRA, was hinzukommt. 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 grundsätzlich ein PDE. Die Kernfrage ist die Einstufung: Produkte ohne Anhang-III- oder Anhang-IV-Kernfunktion fallen in die Standard-Kategorie und dürfen per Selbstbewertung (Modul A, interne Kontrolle) mit CE gekennzeichnet werden. Nur die in Anhang III als „wichtig" gelisteten Kategorien lösen strengere Pfade aus - und einige Funk-Produkte fallen genau darunter, weil ihre Kernfunktion Routing, VPN oder eine Sicherheitsfunktion ist (Art. 7 Abs. 1).

Die Grenzziehung ist im Einzelfall wichtig und keine Formsache: Ob ein Gateway „nur" verbindet oder als Router bzw. Sicherheitskomponente seine Kernfunktion hat, verschiebt es von der Selbstbewertung zur notifizierten Stelle. Die 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, deren Fundstellen mit Einschränkungen veröffentlicht sind (Durchführungsbeschluss (EU) 2025/138), 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. Harmonisierte Normen zum CRA sind beauftragt (M/606), am 9. Oktober 2026 aber noch nicht im Amtsblatt veröffentlicht. Wer nach EN 18031 gebaut hat, hat wichtige Teile von Anhang I Teil I bereits umgesetzt; Schwachstellenbehandlung, SBOM, Unterstützungszeitraum und Meldungen kommen hinzu. Wie wir Funkprodukte gegen EN 18031 prüfen, beschreibt die Seite EN 18031 und Funkanlagenrichtlinie.

• RED-DA (VO 2022/30): greift seit 01.08.2025 für bestimmte Funkanlagen, vor allem solche, die über das Internet kommunizieren können, auf die Cybersicherheits-Grundzüge (Art. 3.3 d/e/f). Die Delegierte VO (EU) 2026/339 hebt die VO mit Wirkung vom 11.12.2027 auf.
• CRA: horizontal und breiter: Schwachstellen-Handling über den Unterstützungszeitraum, SBOM, CVD, Meldepflichten. Deckt ab dem 11.12.2027 auch die Anforderungen nach Art. 3.3 d/e/f ab; die Meldepflicht nach Art. 14 gilt schon seit dem 11.09.2026.
• NIS2: betrifft wesentliche und wichtige 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, etwa als mittlerer oder großer Hersteller elektronischer Erzeugnisse (Anhang II Nr. 5) - ein getrennter Rechtsakt, der nicht mit dem CRA vermischt werden darf.
• AI Act: gilt zusätzlich, sobald ein KI-System verbaut ist (z. B. On-Device-Inferenz); der Umfang der Pflichten hängt von der Risikostufe ab. Separates Regime, keine automatische Kopplung an die Funkzulassung.

SBOM und Lieferkette: der Embedded-OSS-Stack

Funkmodule und Gateways enthalten 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, ggf. ein Web-UI-Framework. Zu prüfen ist, ob diese Komponenten noch in der Version laufen, 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 SBOM verlangt erst der CRA; sie lohnt sich aber schon heute für die Schwachstellenbehandlung. Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Eine allgemeine Veröffentlichungspflicht gibt es nicht - die SBOM ist der Marktüberwachung auf begründetes Verlangen bereitzustellen. 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 Unterstützungszeitraum (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8), eine Policy zur koordinierten Offenlegung (CVD) und die Fähigkeit, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle fristgerecht zu melden. Diese Meldekaskade nach Art. 14 ist gestaffelt - die Fristen exakt zu kennen, ist Pflicht:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis einer aktiv ausgenutzten Schwachstelle bzw. eines schwerwiegenden Sicherheitsvorfalls.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• Abschlussbericht: bei einer aktiv ausgenutzten Schwachstelle innerhalb von 14 Tagen nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme; bei einem schwerwiegenden Sicherheitsvorfall innerhalb von einem Monat nach der 72-Stunden-Meldung.

Gemeldet wird über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich - eine Einmalmeldung. Hersteller sollten ihre internen PSIRT-Prozesse unabhängig vom Werkzeug aufsetzen und vorhalten. Für einen Funkgeräte-Hersteller ohne dedizierten Security-Prozess ist das der praktisch anspruchsvollste Teil: 24 Stunden verlangen eine definierte Rufkette, Triage und einen Kontakt zur Meldestelle.

Fristen: was zuerst zählt

Zwei CRA-Daten bestimmen die Planung - und sie liegen bewusst auseinander:

• 11.09.2026 - Melde- und Berichtspflichten (Art. 14): die erste harte Herstellerpflicht. Seitdem müssen aktiv ausgenutzte Schwachstellen und schwerwiegende 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 bereits stehen (Pflicht seit September 2026), die volle Produktkonformität folgt danach (bis zum 11.12.2027). Für Funkgeräte-Hersteller kommt hinzu, dass die RED-DA-Pflichten seit 08/2025 laufen und bis zur Aufhebung der VO 2022/30 zum 11.12.2027 gelten. Die technische Substanz aus EN 18031 ist also ohnehin aufzubauen und fließt direkt in die CRA-Anhang-I-Umsetzung ein.

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 Routing die Kernfunktion des Produkts ist, wäre es unter dem CRA voraussichtlich als wichtiges Produkt der Klasse I (Anhang III) einzuordnen; die Selbstbewertung bliebe nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas (mindestens Stufe „mittel“) möglich, andernfalls käme eine notifizierte Stelle ins Spiel (Modul B+C oder H).

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 aktualisiert, bevor sie zum Meldefall wird. Zweitens richtet er sofort einen PSIRT-Prozess mit Rufkette für die Frühwarnung (unverzüglich, spätestens nach 24 Stunden) und CVD-Kontakt ein, denn die Meldepflicht gilt seit 09/2026. Drittens plant er die Anhang-I-Umsetzung, die Einstufungs-Herleitung und die Konformitätsbewertung so, dass alles zum 11.12.2027 dokumentiert ist. Ergebnis: Die technische Substanz aus EN 18031 fließt in die CRA-Umsetzung ein; SBOM, Schwachstellenbehandlung und Meldungen kommen hinzu.

Was Blackfort für Sie tut

Blackfort Technology begleitet Funkgeräte- und Telekom-Hersteller durch diesen Übergang - von der RED-DA-Basis zur CRA-Umsetzung, mit dem Ziel, nichts doppelt zu erarbeiten:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, ob Ihr Produkt ein PDE ist, ob es Standard, Klasse I oder Klasse II ist, welche RED-Anforderungen bis zum 10.12.2027 gelten und welche CRA-Pflichten schon heute. Nachvollziehbar hergeleitet, zur Prüfung durch Ihre Rechtsabteilung.
• SBOM-Setup: maschinenlesbare Stückliste, etwa in CycloneDX oder SPDX, aus Ihrem Build, inklusive EOL-/OSS-Risikoanalyse für den Embedded-Stack.
• PSIRT und CVD: Aufbau des Meldeprozesses passend zur Art.-14-Kaskade (Frühwarnung, Meldung, Abschlussbericht nach 14 Tagen bzw. 1 Monat), sofort, denn die Pflicht gilt seit dem 11.09.2026.
• Risikobewertung und Threat-Modeling: die dokumentationspflichtige Risikoanalyse nach Art. 13 und Anhang I, methodisch sauber.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13).

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.