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 sind Cybersicherheit, Schutz der Privatsphäre und Schutz vor Betrug für internetfähige Funkanlagen, die seit dem 1. August 2025 in der EU verkauft werden, verbindlich; der delegierte Rechtsakt wird ab dem 11. Dezember 2027 aufgehoben, wenn die Cyberresilienz-Verordnung vollständig gilt. Die harmonisierte Normenreihe EN 18031-1/2/3 ist der freiwillige Weg zur Konformitätsvermutung. 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 ruhten sie – die Anforderungen des Artikels 3.3 gelten nur für die Kategorien oder Klassen von Funkanlagen, die die Kommission durch delegierten Rechtsakt festlegt.
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 einmal verschoben: Die ursprüngliche Frist war August 2024 und wurde verlängert, um Zeit für die harmonisierten Normen zu geben – EN 18031-1/-2/-3:2024, die am 30. Januar 2025 mit Einschränkungen im Amtsblatt aufgeführt wurden. Die Delegierte Verordnung (EU) 2026/339 hebt den delegierten Rechtsakt mit Wirkung vom 11. Dezember 2027 auf, wenn die CRA vollständig gilt.
Bezug zur CE-Kennzeichnung: Im Rahmen der CE-Kennzeichnung ist die EN 18031 die harmonisierte Norm, die im Amtsblatt für diese Anforderungen aufgeführt ist. Ihre Anwendung ist freiwillig, aber ein Hersteller, der sie nicht vollständig anwendet, muss eine notifizierte Stelle einbeziehen (Artikel 17(4) der RED). Die Konformitätserklärung muss durch Nachweise für die Artikel 3.3(d)(e)(f) in der technischen Dokumentation gestützt sein.
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. ATECC608C, 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 – Die EN 18031-3 nennt mehrere Implementierungskategorien für sichere Updates (digitale Signaturen, sichere Kommunikation, Zugriffskontrolle, sonstige); die Kommission hält keine davon für sich genommen für ausreichend für Geräte, die finanzielle Vermögenswerte verarbeiten, sodass diese Klausel keine Konformitätsvermutung begründet und eine notifizierte Stelle die Lösung bewerten muss. Eine hardwareseitig verankerte Verifikation (Secure Boot) ist die stärkste Option. 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:
| Sicherheitsfähigkeit | 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+, ATECC608C, 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 – ANFR + Zoll (DGDDI) Die ANFR (Agence nationale des fréquences) führt die Marktüberwachung von Funkanlagen gemäß der RED durch. 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 kann zu Korrekturmaßnahmen oder zur Rücknahme vom Markt führen. Die Maßnahmen werden über das Informations- und Kommunikationssystem der EU für die Marktüberwachung (Verordnung (EU) 2019/1020, Artikel 34) mit den anderen Mitgliedstaaten geteilt; Produkte, die ein ernstes Risiko darstellen, werden zusätzlich über Safety Gate / RAPEX gemeldet. 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 (ab dem 11. Dezember 2027 aufgehoben) | 11. Dezember 2027 (Meldepflichten: 11. September 2026) |
| Anwendungsbereich | Internetfähige Funkanlagen | Produkte mit digitalen Elementen |
| Norm | EN 18031-1/2/3 | Harmonisierte CRA-Normen in Vorbereitung (Normungsauftrag M/606) |
| SBOM erforderlich | Nein | Ja |
| Meldung von Schwachstellen | Nein | Ja (seit dem 11. Sept. 2026: 24-Stunden-Frühwarnung an das als Koordinator benannte CSIRT und die ENISA) |
| Beziehung | Ab dem 11. Dezember 2027 durch die Delegierte Verordnung (EU) 2026/339 aufgehoben | Breiter gefasst; ihr Anhang I deckt die Anforderungen des Artikels 3.3(d)(e)(f) der RED ab |
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 Konformitäts-Checkliste
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 oder softwarebasierte Verifikation in der technischen Dokumentation dokumentiert
- 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 Anforderungen gelten seit dem 1. August 2025 für jede Einheit, die in der EU in Verkehr gebracht wird.
Ü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)