Was ist der delegierte Rechtsakt zur RED?
Der delegierte Rechtsakt zur RED (Delegierte Verordnung (EU) 2022/30 der Kommission) aktiviert die Artikel 3.3(d), (e) und (f) der Funkanlagenrichtlinie (2014/53/EU). Damit werden Cybersicherheit, Schutz der Privatsphäre und Schutz vor Betrug für alle internetfähigen Funkanlagen, die ab dem 1. August 2025 in der EU verkauft werden, verbindlich. Die harmonisierte Normenreihe EN 18031-1/2/3 definiert die spezifischen technischen Anforderungen. Bei Nichtkonformität dürfen Produkte für Funkanlagen rechtlich nicht mehr mit der CE-Kennzeichnung versehen werden.
Der regulatorische Kontext: Was sich geändert hat
Die Funkanlagenrichtlinie (RED) enthält die Artikel 3.3(d), (e) und (f) bereits seit 2014. Diese Artikel definieren Schutzanforderungen für Netzwerke, personenbezogene Daten und die Betrugsprävention. Zehn Jahre lang waren sie optional – Hersteller konnten sich auf sie berufen, waren aber nicht dazu verpflichtet.
Der delegierte Rechtsakt zur RED (EU 2022/30) ändert das. Ab dem 1. August 2025 sind diese Anforderungen für alle Funkanlagen, die sich mit dem Internet verbinden können – direkt oder über ein Gateway – verbindlich.
Das Datum wurde bereits einmal verschoben: Die ursprüngliche Frist war August 2024 und wurde verlängert, um Zeit für die Fertigstellung und Veröffentlichung der harmonisierten Norm EN 18031 zu geben (was Anfang 2025 geschah). Es wird keine weiteren Verlängerungen geben.
Bezug zur CE-Kennzeichnung: Der Rahmen der CE-Kennzeichnung umfasst nun die EN 18031 als eine erforderliche harmonisierte Norm für internetfähige Funkanlagen. Eine Aktualisierung der Konformitätserklärung ohne Prüfnachweis nach EN 18031 führt zu einer unvollständigen technischen Dokumentation.
Wer betroffen ist
Wenn Ihr Produkt über eine Funkschnittstelle verfügt und – direkt oder über ein verbundenes Gerät – das Internet erreichen kann, fällt es in den Anwendungsbereich:
| Gerätetyp | Im Anwendungsbereich? |
|---|---|
| WLAN-fähige Geräte (alle Kategorien) | ✅ Ja |
| Bluetooth-Geräte, die über ein Smartphone oder einen Hub weiterleiten | ✅ Ja |
| Mobilfunk-IoT (LTE-M, NB-IoT, Cat-1) | ✅ Ja |
| Smart-Home-Sensoren, Gateways, Hubs | ✅ Ja |
| Wearables (Smartwatches, Fitness-Tracker, Gesundheitsmonitore) | ✅ Ja |
| Babyfone, Kinderzimmerkameras | ✅ Ja |
| Drahtlose Zahlungsterminals | ✅ Ja (auch EN 18031-3) |
| Zigbee/Z-Wave-Geräte, die mit einem Internet-Gateway verbunden sind | ✅ Ja |
| Eigenständiges Bluetooth-Gerät ohne Datenpfad zum Internet | Graubereich – holen Sie rechtlichen Rat ein |
Wichtig: Der Anwendungsbereich umfasst „internetfähige Funkanlagen“ – nicht nur Verbraucherprodukte. Industrielles IoT, vernetztes medizinisches Zubehör (nicht als MDR-Produkt eingestuft), intelligente Gebäudesensoren und Logistik-Tracker fallen alle in den Anwendungsbereich, wenn sie eine Funkschnittstelle mit einem Datenpfad zum Internet haben.
Was die EN 18031 tatsächlich fordert
Die harmonisierte Normenreihe EN 18031 besteht aus drei Teilen, die jeweils einem Artikel des delegierten Rechtsakts zugeordnet sind:
EN 18031-1 – Netzwerkschutz (Art. 3.3(d))
Das Gerät darf das Netzwerk nicht schädigen oder Netzwerkressourcen missbrauchen. In Bezug auf die Hardware bedeutet das:
- Netzwerkschutz – Das Gerät darf das Netzwerk nicht aktiv schädigen. Dienste dürfen nicht standardmäßig offengelegt sein (kein offenes Telnet, ungeschütztes MQTT oder offene Debug-Ports). Die Implementierung von exponentiellem Backoff und Ratenbegrenzung für die Wiederverbindung wird dringend empfohlen, um die Konformität nachzuweisen.
- Softwareintegrität [SUM-2] – EN 18031-1 fordert, dass das Gerät nur Software installiert, deren Integrität und Authentizität zum Zeitpunkt der Installation gültig sind. Die Norm ist technologieneutral: Akzeptierte Implementierungen umfassen digitale Signaturen, die im Bootloader verifiziert werden, die ausschließliche Bereitstellung über einen sicheren Kanal von einer authentifizierten Quelle oder eine Zugriffskontrolle in Kombination mit einem Hash. Hardwarebasierter Secure Boot (ROM-resident, Verifikation auf Chipebene) ist die stärkste Implementierung und wird für erhöhte Bedrohungsmodelle oder Geräte, die auch der EN 18031-3 (Schutz vor Betrug) unterliegen, dringend empfohlen. Er wird jedoch von der EN 18031-1 nicht explizit vorgeschrieben – eine softwarebasierte Verifikation mit gründlicher Dokumentation in der technischen Dokumentation kann SUM-2 erfüllen.
Auswirkung auf die technische Dokumentation: Wenn Sie SUM-2 durch digitale Signaturen implementieren, müssen die Verwaltung der Signaturschlüssel und die Verifikationslogik des Bootloaders gründlich dokumentiert werden. Schwache oder undokumentierte Verifikationsketten sind die häufigste Ursache für das Scheitern der SUM-2-Bewertung.
EN 18031-2 – Schutz der Privatsphäre (Art. 3.3(e))
Das Gerät muss personenbezogene Daten und die Privatsphäre der Nutzer schützen. Gilt für alle Geräte, die personenbezogene Daten, Verkehrs- oder Standortdaten verarbeiten, speichern oder übertragen.
- Hardwarebasierte Schlüsselspeicherung (oder äquivalenter SSM) – Die EN 18031 ist technologieneutral: Sie schreibt einen sicheren Speichermechanismus (Secure Storage Mechanism, SSM) für kryptografische Schlüssel vor, keine spezifische Implementierung. Akzeptierte Ansätze sind ARM TrustZone mit einem Schlüsselverwaltungsdienst, ein externes Secure Element (z. B. ATECC608B, STSAFE-A, SE050) oder eine MCU mit OTP/eFuse-basierter Schlüsselspeicherung. Softwarebasierte SSM-Implementierungen ohne Hardware-Isolierung sind möglich, erfordern aber eine umfassende Begründung in der technischen Dokumentation – die meisten Prüflabore werden diese genau unter die Lupe nehmen.
- Keine universellen Standardpasswörter – Geräte dürfen nicht mit gemeinsam genutzten Werkszugangsdaten ausgeliefert werden. Jede Einheit benötigt ein eindeutiges Passwort, oder das Gerät muss bei der ersten Verwendung eine Passwortänderung mit hardwaregestützter Provisionierung erzwingen.
- Architektur zur Datenminimierung – Das Gerät sollte nicht mehr Daten sammeln oder übertragen, als notwendig ist. Dies ist in erster Linie eine Anforderung an das Software-/Firmware-Design, aber Hardware-Entscheidungen (z. B. der Einbau eines Mikrofons, wenn es nicht benötigt wird) sind relevant.
- Speziell für Geräte für Kinder – EN 18031-2 enthält spezifische Anforderungen für Geräte, die für Kinder bestimmt sind: Schnittstellen zur Kindersicherung, eingeschränkte Datenerfassung und strengere Zugriffskontrollen.
Auswirkung auf die Hardware: Ein ESP32, der WLAN-Zugangsdaten und Geräteschlüssel im NVS-Flash (unverschlüsselt, ohne Schutz auf Softwareebene) speichert, erfüllt die SSM-Anforderungen nicht. Unabhängig davon, ob ein hardware- oder softwarebasierter Schlüsselschutz verwendet wird, gilt: Klartextschlüssel, die aus dem Anwendungskontext zugänglich sind = nicht konform.
EN 18031-3 – Schutz vor Betrug (Art. 3.3(f))
Betrifft Geräte, die Finanztransaktionen, Geldwerte oder virtuelle Währungen abwickeln:
- Hardwareseitig verankerte Firmware-Verifikation – Bei Zahlungsgeräten muss die Verifikationskette der Firmware hardwareseitig verankert sein (Secure Boot). Eine digitale Signatur allein, ohne einen hardwarebasierten Vertrauensanker, der die Verifikation absichert, wird für dieses Bedrohungsmodell im Allgemeinen als unzureichend angesehen – die gesamte Verifikationskette wird kompromittiert, wenn der Verifizierer selbst ausgetauscht werden kann.
- Sichere Zahlungsschnittstellen – Schnittstellen, die Zahlungsdaten verarbeiten, müssen auf Hardwareebene isoliert sein.
- Mechanismen zur Transaktionsverifikation – Geräte müssen Schutzmaßnahmen gegen wiederholte oder eingeschleuste Transaktionsbefehle implementieren.
Wen das betrifft: Vernetzte Point-of-Sale-Terminals, E-Wallet-Wearables, Zubehör für mobiles Bezahlen, Hardware-Wallets für Kryptowährungen, intelligente Zähler mit Vorauszahlungsfunktion.
Hardware-Entscheidungen, die Sie nicht patchen können
Dies ist der Abschnitt, den die meisten Teams übersehen. Mehrere Anforderungen der EN 18031 lassen sich direkt auf Architekturentscheidungen auf Chipebene zurückführen, die nicht nachträglich in der Firmware korrigiert werden können:
| Anforderung | Hardware-Entscheidung | MCUs, die dies unterstützen |
|---|---|---|
| Hardwarebasierter Secure Boot | ROM-Bootloader + eFuse/OTP-Schlüsselspeicher | STM32U5, nRF5340, ESP32-S3, i.MX RT1170, STM32H5 |
| Hardwarebasierte Schlüsselisolierung | TrustZone oder Secure Element | ARM Cortex-M33+, ATECC608B, SE050, STSAFE-A |
| Rollback-Schutz (Best Practice, nicht normativ – EN 18031-1 Klausel 6.3.3 Leitfaden) | Monotoner Hardware-Zähler (OTP/eFuse) oder sicherer Versionszähler | nRF9160, STM32H5, ESP32-S3, STM32WBA |
| Geräteindividuelle Zugangsdaten | Infrastruktur für die Fertigungsprovisionierung | Erfordert das Brennen von eFuses oder die SE-Provisionierung in der Produktion |
| TRNG für die Schlüsselgenerierung | On-Chip-Zufallszahlengenerator (True Random Number Generator) | Die meisten modernen MCUs – im Datenblatt prüfen |
Warnung zu älteren Bauteilen: STM32F4, STM32F7 und ähnliche ältere Cortex-M4/M7-Bauteile ohne TrustZone haben nur eine begrenzte Unterstützung für Secure Boot. Designs, die auf diesen Chips basieren, erfordern möglicherweise eine Platinenrevision, um konform zu sein – kein Firmware-Update. Wenn Sie auf diesen Plattformen entwickeln, empfehlen wir eine Architekturprüfung, bevor Sie sich auf die Fertigung festlegen.
Die Realität der nationalen Durchsetzung
Der delegierte Rechtsakt ist EU-Recht, das national durchgesetzt wird. Die Durchsetzung ist nicht in allen Mitgliedstaaten einheitlich, und das Ausmaß der Marktüberwachungsaktivitäten variiert:
🇩🇪 Deutschland – Bundesnetzagentur (BNetzA) Deutschland hat historisch gesehen eine der aktivsten Produktmarktüberwachungen in der EU. Die BNetzA kauft und prüft Produkte unabhängig, führt gezielte Kampagnen durch und entfernt aktiv nicht konforme Produkte. Produkte, die auf Amazon.de und über deutsche Distributoren verkauft werden, sollten von einer Überprüfung ausgehen.
🇫🇷 Frankreich – DGCCRF + Zoll (DGDDI) Die DGCCRF (Generaldirektion für Wettbewerb, Verbraucherangelegenheiten und Betrugsbekämpfung) ist für die Produktkonformität zuständig. Der französische Zoll prüft Importe aktiv auf Konformitätsdokumentation und kann Sendungen bis zur Überprüfung der Unterlagen zurückhalten.
🇳🇱 Niederlande – RDI (Rijksinspectie Digitale Infrastructuur) Die RDI ist ein aktiver Teilnehmer an EU-weiten ADCO-RED-Gemeinschaftsaktionen. Die Niederlande sind ein wichtiger Einfuhrhafen für Waren auf dem EU-Markt – die RDI hat Einfluss bei Zollkontrollen.
🇸🇪 Schweden – PTS (Post- och telestyrelsen) Bekannt für die proaktive Durchsetzung bei IoT und vernetzten Verbrauchergeräten. Aktiv in gesamteuropäischen Überwachungskampagnen.
Praktische Konsequenz: Eine von einer nationalen Behörde festgestellte Nichtkonformität führt zum Marktrückruf und zur Meldung an das Safety Gate / RAPEX-System. Sobald ein Produkt gemeldet ist, werden andere Mitgliedstaaten automatisch benachrichtigt. Ein Konformitätsmangel in Deutschland ist praktisch ein EU-weiter Konformitätsmangel.
Die Beziehung zur CRA
Der delegierte Rechtsakt zur RED und die Cyberresilienz-Verordnung (CRA) (EU 2024/2847) überschneiden sich im Anwendungsbereich für vernetzte Hardware:
| Aspekt | Delegierter Rechtsakt zur RED | CRA |
|---|---|---|
| Gilt ab | 1. August 2025 | 11. Dezember 2027 |
| Anwendungsbereich | Internetfähige Funkanlagen | Alle Produkte mit digitalen Elementen |
| Norm | EN 18031-1/2/3 | EN 18031 + IEC 62443 + neue CRA-Normen |
| SBOM erforderlich | Nein | Ja |
| Meldung von Schwachstellen | Nein | Ja (24h an ENISA ab Sep 2026) |
| Beziehung | CRA wird die Cybersicherheitsanforderungen der RED ersetzen | Breiter gefasst; absorbiert den Anwendungsbereich des delegierten Rechtsakts zur RED |
Praktische Implikation: Die heutige Konformität mit EN 18031 gibt Ihnen die sicherheitstechnische Hardware-Grundlage für die CRA-Bereitschaft im Jahr 2027. Sie deckt nicht die SBOM, das Schwachstellenmanagement oder die Verpflichtungen über den Lebenszyklus ab – dies sind CRA-spezifische Ergänzungen. Unsere CRA-Hardware-Konformitäts-Checkliste enthält die vollständigen CRA-Anforderungen.
Die Checkliste vor August
Für jedes internetfähige Funkprodukt, das sich derzeit auf dem EU-Markt befindet oder in aktiver Entwicklung ist:
Anwendungsbereich:
- Bestätigen, dass das Produkt einen Datenpfad zum Internet hat (direkt oder über ein Gateway)
- Identifizieren, welche Teile der EN 18031 gelten (18031-1 immer; -2 bei personenbezogenen Daten; -3 bei Zahlungen)
Hardware:
- Secure Boot: hardwaregestützte Kette bestätigt und implementiert
- SSM für Schlüsselspeicherung: TrustZone + Schlüssel-Service, Secure Element, OTP/eFuse oder softwarebasiert mit dokumentierter Risikobegründung in der technischen Dokumentation
- Anti-Rollback: monotoner Hardware-Zähler vorhanden und integriert
- Standardpasswort: pro Gerät eindeutig oder erzwungene Änderung bei Erstinbetriebnahme bestätigt
- TRNG: Hardware-Zufallszahlengenerator im Chip oder extern
Dokumentation:
- Technische Dokumentation mit Prüfnachweisen nach EN 18031-x aktualisiert
- Konformitätserklärung aktualisiert, um auf die Artikel 3.3(d)(e)(f) zu verweisen
- Konformitätsbewertungspfad für EN 18031 bestätigt – Selbsterklärung (Modul A) ist für die meisten Geräte zulässig; spezifische Produktmerkmale (Mechanismen zur Passwortumgehung, Geräte für Kinder, Zahlungsfunktionalität) können eine notifizierte Stelle erfordern. Prüfen Sie dies anhand der für Ihr spezifisches Produkt geltenden Klauseln.
Wenn heute bei einem der Hardware-Punkte Lücken bestehen, müssen Sie eine Entscheidung über eine Platinenrevision treffen. Die Vorlaufzeit für die Fertigung und der Zeitplan für erneute Prüfungen machen den August 2025 sehr nah.
Über den Autor
Vladimír Vician ist der Gründer von Inovasense, einem in der EU ansässigen Unternehmen für die Entwicklung von Embedded Hardware und die technische Begleitung der Konformitätsbewertung. Mit über 10 Jahren Erfahrung im Design von Embedded Hardware arbeitet er mit Hardware-Herstellern an der vollständigen Einhaltung der EU-Vorschriften – von der Auswahl der Chips und der Erstellung der technischen Dokumentation bis hin zur CE-Kennzeichnung und der Vorbereitung auf die CRA. Er ist der Autor des MCU vs MPU Architecture Advisor Tools, das von Hardware-Teams in ganz Europa genutzt wird.
Auf LinkedIn vernetzen · Inovasense Embedded Security & IoT
Offizielle Referenzen
- Delegierte Verordnung (EU) 2022/30 der Kommission – Volltext des delegierten Rechtsakts zur RED – EUR-Lex
- Richtlinie 2014/53/EU (RED) – Basisrichtlinie – EUR-Lex
- Europäische Kommission – Seite zur Funkanlagenrichtlinie (Abschnitt Artikel 3.3(d)(e)(f)) – Europäische Kommission
- Pressemitteilung der Europäischen Kommission – Kommission stärkt Cybersicherheit von Drahtlosgeräten (Okt. 2021) – Europäische Kommission
- ADCO RED – Gruppe für die Zusammenarbeit der Verwaltungsbehörden im Bereich der RED – Europäische Kommission
Quellen und offizielle Verweise
- Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Amtsblatt der EU)
- RED Delegated Act — Regulation (EU) 2022/30 — EUR-Lex (Amtsblatt der EU)
- Radio Equipment Directive — 2014/53/EU — EUR-Lex (Amtsblatt der EU)
- Medical Device Regulation — Regulation (EU) 2017/745 — EUR-Lex (Amtsblatt der EU)