Praxis-Assessment: Einen Wi-Fi-Smart-Plug gegen DIN EN 18031-1 bewerten

September 25, 2026 · Reading Time: 24-30 minutes

Zwölf Wochen lang haben wir die Bausteine der RED-DA-Bewertung einzeln betrachtet: Anwendungsbereich, Normteile, Assets, Schnittstellen, Authentifizierung, Scoping und Bewertungspfad. Zum Abschluss des ersten Quartals setzen wir diese Bausteine an einem konkreten Produkt zusammen. Wir haben dafür bewusst ein Gerät gewählt, das in vielen Entwicklungsabteilungen als unkritisch gilt: einen Wi-Fi-Smart-Plug, also eine schaltbare Zwischensteckdose mit App-Anbindung. Gerade an solchen Einstiegsgeräten zeigt sich, dass DIN EN 18031-1 nicht nach Produktgröße oder Preis unterscheidet. Der Smart Plug durchläuft nahezu alle Mechanismen der Norm, und an mindestens fünf Stellen entscheidet eine einzelne Designentscheidung über PASS oder FAIL.

Hinzu kommt ein praktischer Aspekt: Ein Smart Plug ist günstig, leicht zu beschaffen und schnell zu untersuchen. Verdachtsfälle nicht konformer Funkanlagen kann jede natürliche oder juristische Person der Bundesnetzagentur melden, darunter auch Wettbewerber und Prüfstellen. Wer Einstiegsgeräte in Verkehr bringt, sollte deshalb davon ausgehen, dass nicht nur die eigene Entwicklung einen genauen Blick darauf wirft.

Kurz gesagt

Unser Referenzgerät, ein Wi-Fi-Smart-Plug mit Cloud-Anbindung, lokaler API und Firmware-Updates über das Netz, führt zu folgendem Ergebnis:

• Scoping: Buchstabe (d) greift über die Internetanbindung, damit ist DIN EN 18031-1 anwendbar. Buchstabe (e) ist gesondert zu prüfen und liegt näher, als viele Hersteller annehmen. Buchstabe (f) greift nicht, weil keine Werttransferfunktion besteht.
• Anwendbare Mechanismen: ACM, AUM, SUM, SSM, SCM, RLM, CCK, GEC und CRY sind für mindestens ein Element anwendbar. NMM und TCM entfallen, weil ein Smart Plug keine Netzwerkausrüstung im Sinne der Norm ist.
• Die fünf typischen Schwachstellen: unverschlüsselte Übergabe der WLAN-Zugangsdaten während der Einrichtung, lokale API ohne oder mit abschaltbarer Authentifizierung, Firmware-Updates ohne wirksame Signaturprüfung, ein geräteübergreifend identischer Schlüssel für die Cloud-Anmeldung sowie veraltete Komponenten im Hersteller-SDK des Funkchips.
• Bewertungspfad: Wird die Norm vollständig angewandt und bietet das Gerät an keiner Stelle die Option, auf ein Passwort zu verzichten, bleibt der Weg über Modul A offen.

Das Assessment zeigt: Der Aufwand eines Smart Plugs liegt nicht in der Komplexität der Hardware, sondern in der Vollständigkeit der Begründungen für jedes einzelne Element.

Das Referenzgerät und seine Annahmen

Ein Praxis-Assessment ist nur so belastbar wie die Beschreibung des Prüfgegenstands. Wir legen deshalb zuerst fest, welches Gerät wir bewerten. Die Merkmale entsprechen einem verbreiteten Aufbau in diesem Marktsegment, das Gerät selbst ist fiktiv.

• Hardware: Wi-Fi-SoC für 2,4 GHz mit Hersteller-SDK, Relais, Taster und Status-LED. Auf der Leiterplatte befinden sich unbestückte UART-Testpunkte.
• Einrichtung: Nach dem ersten Einstecken oder nach einem Werksreset öffnet das Gerät einen eigenen Access Point (Soft-AP). Die App verbindet sich damit und überträgt die Zugangsdaten des Heim-WLANs.
• Betrieb: Das Gerät hält eine dauerhafte TLS-Verbindung zur Cloud des Herstellers. Die App schaltet das Gerät über die Cloud, Zeitpläne werden in der Cloud verwaltet.
• Lokale Steuerung: Für die Einbindung in Smart-Home-Zentralen stellt das Gerät im Heimnetz eine HTTP-API bereit. Darüber lassen sich das Relais schalten, der Cloud-Endpunkt ändern und ein Firmware-Update auslösen.
• Updates: Firmware-Updates werden über die Cloud angeboten und vom Gerät selbst heruntergeladen und installiert.
• Taster: Kurzer Druck schaltet das Relais, langer Druck von zehn Sekunden setzt das Gerät in den Werkszustand zurück.
• Datenverarbeitung: keine Energiemessung, keine lokale Speicherung von Kontodaten. Das Nutzerkonto existiert ausschließlich in App und Cloud.

Die letzte Annahme ist für das Scoping entscheidend, wie der folgende Schritt zeigt.

Schritt 1: Das Scoping führt zu DIN EN 18031-1 und zu einer offenen Frage bei Teil 2

Wir folgen der Prüfkette, die wir im Artikel zum Scoping-Entscheidungsbaum beschrieben haben.

Die Funkanlagen-Eigenschaft ist unstrittig: Das Gerät sendet und empfängt bestimmungsgemäß Funkwellen zur Funkkommunikation. Keine Ausnahme der Richtlinie greift.

Buchstabe (d) ist aktiviert. Nach Artikel 1 Absatz 1 der Delegierten Verordnung (EU) 2022/30 genügt es, dass die Funkanlage selbst über das Internet kommunizieren kann. Der Smart Plug baut seine Cloud-Verbindung über den Heimrouter eigenständig auf.

Buchstabe (e) verdient mehr Aufmerksamkeit, als ihm bei Einstiegsgeräten meist zuteilwird. Maßgeblich ist, ob das Gerät personenbezogene Daten im Sinne der Datenschutz-Grundverordnung verarbeiten kann. Schaltvorgänge, die einem Nutzerkonto zugeordnet in die Cloud übertragen werden, lassen Rückschlüsse auf Anwesenheit und Gewohnheiten eines Haushalts zu. Für dieses Assessment unterstellen wir eine dokumentierte Herstellerentscheidung, nach der Buchstabe (e) für die beschriebene Konfiguration nicht greift. Diese Annahme ist angreifbar und muss im Einzelfall tragfähig begründet werden. Spätestens mit Energiemessung, lokalem Schaltverlauf oder Standortfunktionen spricht vieles für eine zusätzliche Bewertung nach DIN EN 18031-2. Die Faustregel aus unserer Übersicht zu den drei Normteilen, nach der ein Smart Plug in der Regel nur Teil 1 betrifft, gilt nur für Geräte ohne personenbezogene Daten.

Buchstabe (f) greift nicht, weil das Gerät dem Nutzer keine Übertragung von Geld, monetären Werten oder virtuellen Währungen ermöglicht. Die Ausnahmen des Artikels 2 sind nicht einschlägig.

Ergebnis: Das Assessment wird gegen DIN EN 18031-1 geführt, mit dokumentierter und begründeter Entscheidung zu Teil 2.

Schritt 2: Die Asset- und Schnittstellenaufnahme legt die Elemente fest

Die Entscheidungsbäume der Norm werden je Element durchlaufen. Ohne vollständige Liste der Assets und Schnittstellen fehlt die Grundlage dafür. Wie diese Liste systematisch entsteht, haben wir im Guide zur Asset-Identifikation beschrieben.

Die Assets des Smart Plugs

Die Norm unterscheidet Sicherheits-Assets und Netzwerk-Assets. Sicherheits-Assets sind sensible oder vertrauliche Sicherheitsparameter sowie Sicherheitsfunktionen, Netzwerk-Assets sind sensible oder vertrauliche Netzwerkfunktionskonfigurationen sowie Netzwerkfunktionen.

Bewusst nicht in der Liste stehen Relaiszustand und Zeitpläne. Sie steuern die Nutzfunktion des Geräts, nicht dessen Netzwerk- oder Sicherheitsfunktionen. Die Guidance zu [ACM-1] verdeutlicht diese Abgrenzung am Beispiel der Ausgabetaste einer Kaffeemaschine, die nicht unter die Anforderung fällt. Ob solche Daten unter DIN EN 18031-2 relevant werden, ist eine Frage des Scopings aus Schritt 1.

Die Schnittstellen des Smart Plugs

Die Einordnung der Testpunkte folgt der Logik aus unserem Artikel zur Behandlung von UART: Ein Gehäuse, das sich mit handelsüblichem Werkzeug öffnen lässt, macht einen seriellen Zugang nicht ohne Weiteres unerreichbar. Die belastbare Lösung ist, die Konsole in der Serienfirmware zu deaktivieren oder zu blockieren. Grundlagen zur Einordnung von Netzwerkschnittstellen finden Sie im Artikel Netzwerkschnittstellen in DIN EN 18031 verstehen.

Schritt 3: Die Entscheidungsbäume je Mechanismus

Mit Assets und Schnittstellen als Elementen lassen sich die Mechanismen durchlaufen. Die Norm trennt dabei stets zwei Fragen: Ist eine Anforderung für das Element anwendbar, und ist sie, falls ja, angemessen umgesetzt? Die folgende Übersicht fasst die Anwendbarkeit für das Referenzgerät zusammen.

ACM und AUM: Die lokale API entscheidet über den Bewertungspfad

Nach [ACM-1] muss das Gerät Zugriffe auf Sicherheits- und Netzwerk-Assets über Zugriffskontrollmechanismen steuern. Die lokale API erlaubt es, den Cloud-Endpunkt zu ändern und ein Update auszulösen. Damit werden eine sensible Netzwerkfunktionskonfiguration verändert und eine Sicherheitsfunktion genutzt. Nach [AUM-1-1] ist für diese Zugriffe über die Netzwerkschnittstelle eine Authentifizierung erforderlich.

Die Ausnahme für Netze, in denen physische oder logische Maßnahmen der Einsatzumgebung die Erreichbarkeit auf autorisierte Entitäten begrenzen, liegt beim Heimnetz nahe, trägt aber nicht von selbst. Die Guidance hält fest, dass eine Vertrauensbeziehung zu einem Netz, etwa der Besitz der WLAN-Zugangsdaten, zur Authentifizierung herangezogen werden kann. Da Guidance-Abschnitte keine Konformitätsvermutung begründen, muss der Hersteller diese Argumentation am Anforderungstext führen. In einem Heimnetz mit Gastgeräten, Mitbewohnern und anderen vernetzten Produkten ist das schwer zu begründen. Wie die Authentifizierung an den einzelnen Zugriff und nicht an die Schnittstelle anknüpft, haben wir im Artikel zum Authentifizierungs-Mythos ausgeführt.

Wird für die lokale API ein Passwort verwendet, greifen die Anforderungen an die Passwortstärke. Ein werkseitiges Passwort muss nach [AUM-5-1] je Gerät eindeutig sein, dem Stand der Technik bei der Stärke entsprechen und vom Nutzer vor oder bei der ersten Verwendung geändert werden. Hier liegt der kritische Punkt: Bietet die App oder die API die Option, auf ein Passwort zu verzichten, entfällt nach dem Durchführungsbeschluss (EU) 2025/138 die Konformitätsvermutung. Was das für die Einbindung einer benannten Stelle bedeutet, haben wir im vorherigen Artikel beschrieben. Hinzu kommt der Schutz gegen Brute-Force-Angriffe nach [AUM-6], etwa durch Zeitverzögerungen nach Fehlversuchen.

Für den Taster greift [AUM-1-2], weil ein langer Druck die Netzwerkkonfiguration zurücksetzt. Die Ausnahme für physische Maßnahmen der Einsatzumgebung lässt sich hier plausibel begründen: Wer den Taster betätigen kann, hat physischen Zugang zum Gerät in einem privaten Haushalt. Die Begründung gehört trotzdem in die Dokumentation, denn die Ausnahme ist keine Freistellung, sondern eine Begründungspflicht.

SUM: Die Signaturprüfung muss vor der Installation greifen

Das Gerät verfügt über ein Update-Verfahren, [SUM-1] ist damit erfüllt. Nach [SUM-2] darf jedes Update-Verfahren nur Software installieren, deren Integrität und Authentizität zum Zeitpunkt der Installation gültig sind. In der Praxis wird das üblicherweise über eine digitale Signatur und einen Vertrauensanker im Gerät gelöst. Eine TLS-Verbindung zum Update-Server allein genügt nicht, wenn das Gerät das Image selbst nicht prüft oder die Prüfung über die lokale API umgangen werden kann.

[SUM-3] verlangt, dass Updates ohne menschliches Eingreifen am Gerät, über eine geplante Installation mit Freigabe oder über eine ausgelöste Installation unter Aufsicht eingespielt werden können. Beim Smart Plug ist die automatische Installation über die Cloud der naheliegende Weg. Zu dokumentieren ist, welche Softwareteile davon erfasst sind, insbesondere ob auch der Funk-Stack des SoC aktualisierbar ist.

SSM und CCK: Gespeicherte Geheimnisse und eindeutige Schlüssel

Nach [SSM-1] sind persistent gespeicherte Sicherheits- und Netzwerk-Assets durch sichere Speichermechanismen zu schützen, [SSM-2] verlangt Integritätsschutz, [SSM-3] Vertraulichkeitsschutz für vertrauliche Parameter. Die Ausnahme über die Einsatzumgebung ist beim Smart Plug schwer zu begründen: Die Geräte werden weiterverkauft, verschenkt und entsorgt, und die gespeicherten WLAN-Zugangsdaten verlassen mit ihnen den Haushalt. Ein externer Flash-Speicher lässt sich mit geringem Aufwand auslesen. Die übliche Antwort ist die Flash-Verschlüsselung des SoC in Kombination mit einem geschützten Schlüsselspeicher.

Für die vertraulichen kryptografischen Schlüssel verlangt [CCK-1] eine Sicherheitsstärke von mindestens 112 Bit, [CCK-2] eine Erzeugung nach dem Stand der Technik. Besonders häufig scheitern Einstiegsgeräte an [CCK-3]: Vorinstallierte vertrauliche Schlüssel müssen praktisch je Gerät eindeutig sein. Ein Cloud-Schlüssel, der in der gesamten Serie identisch in der Firmware steckt, erfüllt diese Anforderung nicht, weil ein einziges ausgelesenes Gerät die Anmeldedaten aller Geräte offenlegt.

SCM: Die Einrichtung ist der schwächste Moment

Nach [SCM-1] muss das Gerät Sicherheits- und Netzwerk-Assets über Netzwerkschnittstellen mit sicheren Kommunikationsmechanismen übertragen. Für die Cloud-Verbindung ist das mit TLS nach dem Stand der Technik in der Regel gut lösbar. Nach [SCM-2] bis [SCM-4] sind Integrität und Authentizität, Vertraulichkeit sowie Schutz vor Wiedereinspielung zu gewährleisten. Voraussetzung ist eine vollständige Prüfung des Serverzertifikats, die zugleich unter [AUM-3] fällt.

Kritischer ist die Einrichtung. Überträgt die App die WLAN-Zugangsdaten über einen offenen Soft-AP per unverschlüsseltem HTTP, wird eine vertrauliche Netzwerkfunktionskonfiguration ungeschützt übertragen, und das in Funkreichweite außerhalb der Wohnung. Die Ausnahme in [SCM-1] für Assets, deren Offenlegung Teil des Verbindungsaufbaus ist, trägt hier nicht, weil die Zugangsdaten nicht den Soft-AP-Aufbau betreffen, sondern als Nutzdaten übertragen werden. Lösungsansätze sind ein gerätespezifisch gesicherter Soft-AP, eine verschlüsselte Übertragung auf Anwendungsebene mit Schlüsselaustausch oder ein gesichertes Bluetooth-Provisioning. Die Guidance nennt für Geräte mit eingeschränkter Benutzerschnittstelle zusätzliche Maßnahmen wie ein begrenztes Zeitfenster für die Kopplung, als Beispiel und nicht als Spezifikation.

Die lokale API ist ebenfalls zu betrachten. Werden darüber Passwort oder Cloud-Endpunkt übertragen, gelten dieselben Anforderungen.

RLM, NMM und TCM: Nur einer der drei Resilienzmechanismen greift

[RLM-1] verlangt Mechanismen, die die Auswirkungen von Denial-of-Service-Angriffen auf Netzwerkschnittstellen mindern und das Gerät nach dem Angriff in einen definierten Zustand zurückführen. Ausgenommen sind Schnittstellen, die nur im lokalen Netz ohne Zusammenwirken mit anderen Netzen genutzt werden, sowie Schnittstellen, bei denen andere Geräte im Netz ausreichend schützen. Die WLAN-Schnittstelle des Smart Plugs kommuniziert mit dem Internet, die erste Ausnahme greift also nicht. Wer sich auf den Schutz durch den Heimrouter beruft, muss begründen, warum dieser für das konkrete Gerät ausreicht. In der Regel ist es einfacher, den definierten Zustand selbst herzustellen, etwa durch einen Watchdog, Ratenbegrenzung und einen automatischen Wiederaufbau der Cloud-Verbindung.

[NMM-1] und [TCM-1] gelten nur für Netzwerkausrüstung. Die Norm definiert diese als Gerät, das Daten zwischen verschiedenen Netzen austauscht, um andere Geräte dauerhaft direkt mit dem Internet zu verbinden. Ein Smart Plug tut das nicht. Beide Anforderungen sind nicht anwendbar, die Begründung ist kurz, gehört aber dennoch in die Dokumentation.

GEC und CRY: Angriffsfläche und Stand der Technik

Die allgemeinen Gerätefähigkeiten sind beim Smart Plug besonders ergiebig:

• [GEC-1], bekannte Schwachstellen: Das Gerät darf keine öffentlich bekannten ausnutzbaren Schwachstellen enthalten, die Sicherheits- oder Netzwerk-Assets betreffen, soweit sie nicht unter eine der Ausnahmen fallen. Hersteller-SDKs von Funkchips enthalten TLS-Bibliotheken, Netzwerk-Stacks und Bootloader, deren Versionsstand häufig nicht aktiv verfolgt wird. Ohne Komponentenliste lässt sich [GEC-1] nicht belastbar nachweisen.
• [GEC-2], Werkszustand: Im Werkszustand dürfen nur Schnittstellen und Dienste offen sein, die für die Einrichtung oder den Grundbetrieb erforderlich sind. Ein in der Entwicklung genutzter Telnet- oder Debug-Dienst hat in der Serienfirmware nichts zu suchen.
• [GEC-3], optionale Dienste: Die lokale API ist für den Grundbetrieb nicht erforderlich und damit ein optionaler Dienst. Ist sie im Werkszustand aktiv, muss ein autorisierter Nutzer sie aktivieren und deaktivieren können.
• [GEC-5], physische Schnittstellen: Taster und LED sind für die Funktion erforderlich. Für die UART-Testpunkte gilt die Bewertung aus Schritt 2.
• [GEC-6], Eingabevalidierung: Zu validieren sind Eingaben am Einrichtungsendpunkt des Soft-AP, an der lokalen API und in den Nachrichten aus der Cloud, soweit sie Sicherheits- oder Netzwerk-Assets betreffen können.

Die Beschreibung der offenen Schnittstellen und Dienste in der Nutzerdokumentation regelt [GEC-4]. Die Tabelle ZA.1 der Norm führt Abschnitt 6.10.4 bei den Abschnitten zu Buchstabe (d) nicht auf. Eine vollständige Nutzerdokumentation ist für die Konformitätsargumentation dennoch hilfreich, weil sie die Angaben zu [GEC-2] und [GEC-3] nachvollziehbar macht.

[CRY-1] verlangt schließlich kryptografische Verfahren nach dem Stand der Technik für den Schutz von Sicherheits- und Netzwerk-Assets. Das betrifft die TLS-Konfiguration, das Signaturverfahren für Updates und die Speicherverschlüsselung gleichermaßen.

Die fünf Stellen, an denen Einstiegsgeräte am häufigsten scheitern

Aus dem Durchlauf ergeben sich fünf Befunde, die bei Smart Plugs und vergleichbaren Einstiegsgeräten immer wieder auftreten:

1. WLAN-Zugangsdaten im Klartext während der Einrichtung. Offener Soft-AP, unverschlüsseltes HTTP.
   Befund unter [SCM-1] und [SCM-3].
2. Lokale API ohne Authentifizierung oder mit abschaltbarem Passwort. Die Begründung über das Heimnetz fehlt oder stützt sich nur auf die Guidance.
   Befund unter [AUM-1-1], im zweiten Fall zusätzlich Verlust der Konformitätsvermutung.
3. Firmware-Update ohne wirksame Signaturprüfung. Das Gerät vertraut dem Transportkanal, prüft aber das Image nicht selbst.
   Befund unter [SUM-2].
4. Identischer Cloud-Schlüssel in der gesamten Serie. Der Schlüssel ist in die Firmware einkompiliert.
   Befund unter [CCK-3], häufig zusätzlich unter [SSM-3].
5. Veraltetes Hersteller-SDK. Bekannte Schwachstellen in TLS-Bibliothek oder Netzwerk-Stack, keine Komponentenliste.
   Befund unter [GEC-1].

Keiner dieser Befunde erfordert teure Hardware, um ihn zu beheben. Alle fünf sind jedoch deutlich günstiger zu lösen, wenn sie vor der Serienfreigabe erkannt werden und nicht erst nach einer Anfrage der Marktüberwachung.

Machen Sie den Selbsttest

Übertragen Sie das Assessment auf Ihr eigenes Produkt. Diese sechs Fragen decken die kritischen Punkte ab:

1. Scoping: Ist die Entscheidung zu Buchstabe (e) dokumentiert und begründet, auch wenn das Ergebnis „nicht anwendbar“ lautet?
2. Einrichtung: Auf welchem Weg und mit welchem Schutz gelangen die WLAN-Zugangsdaten auf das Gerät?
3. Lokale Zugänge: Gibt es eine lokale API, eine Weboberfläche oder einen Dienst, der ohne Authentifizierung Konfiguration verändert oder bei dem der Nutzer auf ein Passwort verzichten kann?
4. Updates: Prüft das Gerät die Signatur jedes Images selbst, bevor es installiert wird?
5. Schlüssel: Sind alle vorinstallierten vertraulichen Schlüssel je Gerät eindeutig?
6. Komponenten: Liegt eine Liste der Softwarekomponenten inklusive SDK vor, und wird sie gegen bekannte Schwachstellen abgeglichen?

Wenn Sie bei einer dieser Fragen zögern, ist das ein guter Zeitpunkt für eine strukturierte Bestandsaufnahme. Gern führen wir die Gap-Analyse gemeinsam mit Ihnen durch und priorisieren die offenen Punkte nach Aufwand und Auswirkung auf den Bewertungspfad.

Jede Entscheidung braucht eine Beschreibung und eine Begründung

DIN EN 18031-1 verlangt für jeden Entscheidungsbaum zwei Arten von Nachweisen: eine Beschreibung des gewählten Pfades je Element und eine Begründung für diesen Pfad. Die Norm führt dafür Kennungen nach dem Muster [E.Info.DT.RLM-1] und [E.Just.DT.RLM-1]. Für einen Smart Plug mit zwei Netzwerkschnittstellen, einem lokalen Dienst, zwei Benutzerschnittstellen und acht Asset-Gruppen entsteht so eine überschaubare, aber vollständige Matrix aus Elementen und Mechanismen.

In diese Matrix gehören auch die Nicht-Anwendbarkeiten. Die Begründung, warum [NMM-1] entfällt, umfasst einen Satz. Die Begründung, warum der Taster ohne Authentifizierung auskommt, einen Absatz. Fehlen beide, fehlt der konzeptuellen Bewertung ihr Gegenstand, und die Prüfung der funktionalen Vollständigkeit etwa mit einem Netzwerk-Scanner deckt spätestens dann Dienste auf, die in keiner Liste stehen. Die Dokumentation muss nicht in getrennten Dokumenten vorliegen, sie muss aber vorhanden und nachvollziehbar sein.

Häufige Fragen

Gilt DIN EN 18031 auch für einfache Smart Plugs? Ja, sobald der Smart Plug selbst über das Internet kommunizieren kann, direkt oder über ein anderes Gerät. Dann greift Buchstabe (d) der Delegierten Verordnung (EU) 2022/30, und DIN EN 18031-1 ist der zugehörige Normteil. Produktgröße und Preis spielen keine Rolle.

Muss ein Smart Plug auch nach DIN EN 18031-2 bewertet werden? Das hängt davon ab, ob das Gerät personenbezogene Daten verarbeiten kann. Energiemessung, Schaltverläufe mit Kontobezug oder Standortfunktionen sprechen dafür. Die Entscheidung ist in jedem Fall zu dokumentieren und zu begründen, auch wenn sie negativ ausfällt.

Welche Mechanismen von DIN EN 18031-1 sind für einen Smart Plug nicht anwendbar? In der Regel NMM und TCM. Beide gelten nur für Netzwerkausrüstung, also für Geräte, die Daten zwischen Netzen austauschen, um andere Geräte dauerhaft direkt mit dem Internet zu verbinden. Die übrigen Mechanismen sind für mindestens ein Element des Smart Plugs anwendbar.

Reicht das WLAN-Passwort als Schutz für die lokale API eines Smart Plugs? Nicht ohne Weiteres. Die Guidance der Norm erlaubt, eine Vertrauensbeziehung zum Netz zur Authentifizierung heranzuziehen, begründet aber keine Konformitätsvermutung. Der Hersteller muss am Anforderungstext von [AUM-1-1] begründen, warum die Einsatzumgebung die Erreichbarkeit auf autorisierte Entitäten begrenzt.

Ist ein offener Soft-AP für die Einrichtung zulässig? Der offene Access Point selbst ist nicht das Problem, sondern die Übertragung der WLAN-Zugangsdaten darüber. Werden sie ohne Schutz übertragen, liegt ein Befund unter [SCM-1] und [SCM-3] vor. Eine Verschlüsselung auf Anwendungsebene oder ein gesichertes Provisioning löst das.

Braucht ein Smart Plug eine benannte Stelle? Nicht zwingend. Wird DIN EN 18031-1 vollständig angewandt und bietet das Gerät an keiner Stelle die Option, auf ein Passwort zu verzichten, ist der Nachweis über Modul A möglich. Eine solche Option in App oder lokaler API lässt die Konformitätsvermutung entfallen.

Wie lange dauert ein Assessment für einen Smart Plug? Das hängt weniger von der Hardware als vom Reifegrad der Dokumentation ab. Liegen Asset-Liste, Schnittstellenbeschreibung und Komponentenliste vor, ist die Bewertung überschaubar. Fehlen sie, entsteht der größte Aufwand in der Rekonstruktion dieser Grundlagen.

Fazit

Ein Wi-Fi-Smart-Plug ist kein Sonderfall der RED DA, sondern ein kompaktes Lehrstück. Er durchläuft neun der elf Mechanismen von DIN EN 18031-1, und an fünf Stellen entscheidet eine einzelne Designentscheidung über das Ergebnis: bei der Einrichtung, der lokalen API, der Signaturprüfung, der Schlüsselerzeugung und dem SDK-Stand. Das Assessment führt alle Bausteine des ersten Quartals zusammen: den Anwendungsbereich, die Zuordnung der Normteile, die Asset- und Schnittstellenaufnahme, die Authentifizierung je Zugriff sowie die Frage nach dem Bewertungspfad, die wir im Artikel zur benannten Stelle beantwortet haben. Entscheidend ist am Ende nicht, ob ein Mechanismus umgesetzt ist, sondern ob für jedes Element nachvollziehbar dokumentiert ist, warum er anwendbar ist oder nicht und wie er erfüllt wird.

Mit dem nächsten Artikel beginnt das nächste Kapitel unserer RED-DA-Reihe, das sich den Kern-Mechanismen Zugriffskontrolle, Authentifizierung und sichere Updates widmet. Den Auftakt macht eine Frage, die sich auch beim Smart Plug stellt: Muss DHCP unter DIN EN 18031 authentifiziert werden?

Sie haben ein vergleichbares Produkt in Entwicklung oder bereits im Markt? In einer Gap-Analyse bewerten wir Ihr Gerät gegen die anwendbaren Teile von DIN EN 18031, vom Scoping über die Asset- und Schnittstellenaufnahme bis zu den Entscheidungsbäumen je Mechanismus. Sie erhalten eine priorisierte Liste der offenen Punkte und eine Einschätzung, ob Modul A für Ihr Produkt erreichbar ist. Mehr dazu auf unserer Seite zur RED-DA-Beratung.

---

Dieser Artikel gibt einen strukturierten Überblick anhand eines fiktiven Referenzgeräts und ersetzt keine Einzelfallbewertung. Maßgeblich sind der Wortlaut der Funkanlagenrichtlinie 2014/53/EU, der Delegierten Verordnung (EU) 2022/30, des Durchführungsbeschlusses (EU) 2025/138 sowie der Normteile DIN EN 18031-1, -2 und -3.