RED Directive: Cybersecurity-Anforderungen für vernetzte Geräte ab 2025

Seit dem 1. August 2025 gelten für alle funkfähigen Geräte, die in der EU in Verkehr gebracht werden, verbindliche Cybersecurity-Anforderungen unter der Radio Equipment Directive (RED). Was viele Produktteams unterschätzt haben: Die Anforderungen greifen tief in den Entwicklungsprozess ein und lassen sich nicht nachträglich durch ein Softwareupdate erfüllen. Wer ein IoT-Gerät entwickeln lässt oder ein Embedded-System für den europäischen Markt plant, muss Sicherheit als Designziel behandeln, nicht als Compliance-Checkbox am Ende.

Die delegierte Verordnung (EU) 2022/30 konkretisiert drei Artikel der RED, die direkt Cybersecurity betreffen: Artikel 3(3)(d), (e) und (f). Sie gelten für nahezu alle internetfähigen Geräte, kindgerichtete Produkte und Geräte, die persönliche Daten verarbeiten. Für Teams in der Elektronikentwicklung bedeutet das: neue Pflichten in Hardware-Design, Firmware-Architektur und Dokumentation.

Table of Contents

Welche Geräte von den neuen Pflichten betroffen sind

Die RED-Cybersecurity-Anforderungen erfassen alle Funkanlagen, die direkt oder indirekt mit dem Internet kommunizieren, Kinderspielzeug und Babyphones mit Funkschnittstelle sowie Geräte, die Gesundheitsdaten, Finanzdaten oder Standortdaten verarbeiten. Das schließt klassische IoT-Geräte (BLE, Wi-Fi, NB-IoT, LTE-M, LoRa), Wearables und industrielle Kommunikationsmodule ein.

Ausgenommen sind Geräte, die ausschließlich im lizenzfreien Sub-GHz-Band ohne Internetanbindung operieren, sowie bestimmte medizinische Produkte, die unter die MDR fallen und dort eigene Cybersecurity-Anforderungen haben. Ein häufiger Fehler: Teams gehen davon aus, dass ein BLE-Gerät ohne direkte Cloudanbindung nicht betroffen ist. Wenn das Gerät jedoch über ein Gateway Daten ins Internet überträgt oder mit einer App kommuniziert, die Nutzerdaten verarbeitet, greift die Verordnung trotzdem.

Konkrete technische Anforderungen der RED Directive

Artikel 3(3)(d) fordert, dass Geräte das Netzwerk nicht schädigen und keine unautorisierten Ressourcen belegen. In der Praxis bedeutet das: sichere Kommunikationsprotokolle (TLS 1.2 oder höher), Schutz vor Replay-Angriffen und keine hartcodierten Netzwerkkonfigurationen.

Artikel 3(3)(e) verlangt Maßnahmen zum Schutz personenbezogener Daten. Das betrifft die gesamte Datenpipeline: sichere Speicherung auf dem Gerät (verschlüsselter Flash, Secure Element oder TrustZone), authentifizierte Übertragung und minimale Datenhaltung. Artikel 3(3)(f) adressiert den Betrugsschutz, insbesondere bei Geräten mit Zahlungsfunktion oder Zugang zu Finanzkonten.

Firmware-Anforderungen mit direkter Hardware-Implikation

Sichere Boot-Chains, signierte Firmware-Updates (OTA) und Mechanismen zur Erkennung von Manipulationen an der Firmware sind keine optionalen Features mehr. Ein Mikrocontroller ohne Hardware-Secure-Boot-Unterstützung, der in einem frühen Schaltungsentwurf ausgewählt wurde, kann diese Anforderungen nicht nachträglich erfüllen. Die Wahl des MCU beeinflusst direkt die Zertifizierbarkeit des Produkts.

Bekannte Falle: Teams implementieren OTA-Updates ohne kryptografische Signaturprüfung, weil der Speicherplatz auf dem Mikrocontroller knapp ist. Das spart 8–12 KB Flash, macht das Gerät aber für Firmware-Injection-Angriffe anfällig und führt bei der Konformitätsbewertung zu einem direkten Ablehnungsgrund.

Fristen und Übergangszeiträume im Überblick

Die Frist lief am 1. August 2025 ab. Geräte, die nach diesem Datum in der EU in Verkehr gebracht werden, müssen die Anforderungen der delegierten Verordnung (EU) 2022/30 vollständig erfüllen. Produkte, die vor diesem Datum bereits auf dem Markt waren, dürfen weiter verkauft werden, bis die Bestände aufgebraucht sind.

Für Teams, die 2026 ein neues IoT-Produkt zur Serienreife bringen wollen, bedeutet das: Die RED-Konformität muss bereits in der Konzeptphase berücksichtigt werden. Eine typische CE-Zertifizierung inklusive RED-Cybersecurity-Prüfung dauert 8–16 Wochen, abhängig von der Komplexität des Geräts und der gewählten Konformitätsbewertungsstelle. Wer das erst nach dem ersten Prototyp angeht, riskiert einen kompletten Hardware-Redesign-Zyklus.

Konformitätsbewertung und Dokumentationspflichten

Für die RED-Cybersecurity-Anforderungen gibt es derzeit noch keine harmonisierten EN-Normen, die eine vollständige Konformitätsvermutung auslösen. Das bedeutet: Hersteller müssen den Nachweis durch eine interne technische Dokumentation erbringen oder eine notifizierte Stelle einschalten.

Die technische Dokumentation muss mindestens umfassen: eine Bedrohungsanalyse (Threat Model) für das Gerät, eine Beschreibung der implementierten Sicherheitsmaßnahmen auf Hardware- und Firmware-Ebene, Testergebnisse für Penetrationstests oder Vulnerability-Assessments sowie eine Erklärung, wie Sicherheitsupdates über die gesamte Produktlebensdauer bereitgestellt werden. Letzteres ist besonders kritisch: Ein Gerät ohne definierten Update-Mechanismus erfüllt die Anforderungen nicht, selbst wenn die initiale Firmware sicher ist.

Selbstdeklaration vs. Drittprüfung

Ohne harmonisierte Norm ist die Selbstdeklaration zwar formal möglich, aber risikoreich. Marktaufsichtsbehörden können die Dokumentation anfordern und bewerten. Eine unabhängige Prüfung durch eine akkreditierte Stelle kostet je nach Gerätekategorie 5.000–20.000 Euro, reduziert aber das Rückrufrisiko erheblich und beschleunigt häufig den internen Freigabeprozess.

Cybersecurity früh in den Entwicklungsprozess integrieren

Security-by-Design ist keine Methodik, sondern eine technische Notwendigkeit. MCU-Auswahl, Speicherarchitektur und Kommunikationsstack müssen Sicherheitsanforderungen als primäre Constraints behandeln, nicht als nachgelagerte Features.

Konkret: Die Entscheidung zwischen einem STM32L4 mit TrustZone und einem günstigeren MCU ohne Hardware-Isolation kostet bei 10.000 Einheiten etwa 0,60–1,20 Euro Mehrkosten pro Gerät. Wenn das Gerät unter Artikel 3(3)(e) fällt und personenbezogene Daten verarbeitet, ist die Variante ohne Hardware-Isolation in vielen Threat-Modellen nicht vertretbar. Der Kostenunterschied ist in diesem Kontext irrelevant gegenüber dem Zertifizierungsrisiko.

Wer ein Hardware-Design beauftragen möchte, sollte sicherstellen, dass das Entwicklungsteam das Threat Model bereits vor dem Schaltplanentwurf erstellt. Änderungen an der Sicherheitsarchitektur nach dem ersten PCB-Layout kosten erfahrungsgemäß 4–8 Wochen Entwicklungszeit.

Risiken bei Nichteinhaltung und Marktauswirkungen

Marktaufsichtsbehörden in Deutschland (BNetzA), Frankreich (ANFR) und anderen EU-Mitgliedsstaaten haben die Befugnis, nicht konforme Geräte vom Markt zu nehmen, Verkaufsverbote auszusprechen und Bußgelder zu verhängen. Die Höhe der Bußgelder variiert je nach Mitgliedsstaat, kann aber in Deutschland bis in den sechsstelligen Bereich gehen.

Das unterschätzte Risiko liegt nicht im Bußgeld, sondern im Marktrückzug. Ein Verkaufsstopp bei einem IoT-Gerät, das in eine größere Systemlösung integriert ist, kann die gesamte Lieferkette eines B2B-Kunden blockieren. Für Scale-ups, die gerade skalieren, ist das ein existenzielles Risiko. Händler und Distributoren verlangen zunehmend die vollständige RED-Konformitätsdokumentation vor der Listung, unabhängig von behördlichen Maßnahmen.

Eine weitere Konsequenz: Investoren und strategische Partner bewerten die regulatorische Reife eines Produkts zunehmend als Teil der Due Diligence. Fehlende oder lückenhafte Cybersecurity-Dokumentation kann eine Finanzierungsrunde verzögern oder M&A-Prozesse blockieren.

Wie Oxeltech bei der RED-Konformität unterstützt

Wir begleiten IoT- und Embedded-Projekte von der ersten Konzeptphase bis zur Serienreife und integrieren RED-Cybersecurity-Anforderungen von Beginn an in den Entwicklungsprozess. Das bedeutet konkret:

Threat Modeling und Sicherheitsarchitektur bereits in der Konzeptphase, bevor die MCU-Auswahl abgeschlossen ist
Hardware-Design mit Fokus auf Secure Boot, Hardware-Isolation und verschlüsselter Datenspeicherung
Firmware-Entwicklung mit signierten OTA-Updates, authentifizierten Kommunikationsprotokollen und minimaler Angriffsfläche
Erstellung der technischen Dokumentation für die Konformitätsbewertung nach RED Artikel 3(3)(d), (e) und (f)
Unterstützung bei der Auswahl und Koordination notifizierter Stellen für die Drittprüfung

Wir haben bereits über 20 Hardwareprodukte durch Zertifizierung und Markteinführung begleitet und kennen die typischen Fallstricke, die zu Verzögerungen und Redesign-Zyklen führen. Wenn du ein IoT-Gerät zertifizieren lassen möchtest oder ein neues Projekt planst, das unter die RED fällt, nimm Kontakt mit uns auf und lass uns gemeinsam die Anforderungen von Anfang an richtig aufsetzen.