EN 303 645

EN 303 645 – Cybersicherheitsstandard für IoT-Geräte für Verbraucher

ETSI EN 303 645 (vollständiger Titel: Cyber Security for Consumer Internet of Things: Baseline Requirements) ist der europäische – und mittlerweile weltweit anerkannte – grundlegende Cybersicherheitsstandard für IoT-Geräte für Verbraucher. Er wurde vom ETSI (Europäisches Institut für Telekommunikationsnormen) entwickelt und im Juni 2020 erstmals veröffentlicht. Der Standard definiert 13 Gruppen von Sicherheitsbestimmungen und eine Reihe von Datenschutzbestimmungen (neun in der aktuellen Version), die das Mindestniveau an Cybersicherheit festlegen, das jedes mit dem Internet verbundene Verbrauchergerät aufweisen sollte.

Die EN 303 645 ist eine freiwillige Basisnorm: Sie wird weder im delegierten Rechtsakt zur RED noch in der CRA referenziert, wohl aber in den Produktsicherheitsvorschriften des Vereinigten Königreichs, und diente als Grundlage für nationale Cybersicherheits-Kennzeichnungssysteme in Singapur und Deutschland sowie in Finnland, bis dort 2024 die Vergabe neuer Kennzeichen eingestellt wurde.

Wichtige Fakten

Die 13 Sicherheitsbestimmungen

Die EN 303 645 gliedert ihre Sicherheitsbestimmungen in 13 Abschnitte (5.1–5.13). Jede einzelne Bestimmung ist entweder verbindlich (SHALL) oder eine Empfehlung (SHOULD); die Abschnitte 5.7, 5.9, 5.10 und 5.12 enthalten ausschließlich Empfehlungen. Eine Empfehlung, die nicht angewandt wird, muss schriftlich begründet werden (Bestimmung 5.0-1):

Bestimmung 1: Keine universellen Standardpasswörter

Die wirkungsvollste Bestimmung. Jedes IoT-Gerät muss entweder:

• ohne Standardpasswort ausgeliefert werden, wobei der Benutzer bei der Einrichtung eines festlegen muss, oder
• über ein gerätespezifisches, eindeutiges Passwort verfügen, das so generiert wird, dass es nicht vorhersagbar ist

Gemeinsam genutzte Standard-Anmeldedaten (z. B. admin/admin, root/1234), die für alle Einheiten eines Modells identisch sind, sind verboten. Diese eine Bestimmung eliminiert den häufigsten IoT-Angriffsvektor des letzten Jahrzehnts – Credential Stuffing gegen Standardpasswörter.

Auswirkungen auf die Hardware: Eindeutige, gerätespezifische Passwörter müssen sicher im nichtflüchtigen Speicher abgelegt sein und ein Zurücksetzen auf Werkseinstellungen überdauern (oder nach dem Zurücksetzen neu generiert werden). Dies erfordert einen Provisionierungsprozess während der Fertigung.

Bestimmung 2: Implementierung einer Richtlinie zur Offenlegung von Schwachstellen

Hersteller müssen eine klare, zugängliche Richtlinie zur Offenlegung von Schwachstellen (Vulnerability Disclosure Policy, VDP) veröffentlichen, die:

• Kontaktinformationen für Sicherheitsforscher bereitstellt
• den Zeitrahmen für die erste Eingangsbestätigung einer Meldung angibt
• die Zeitrahmen für Statusaktualisierungen bis zur Behebung des Problems angibt

Dies ist eine organisatorische Anforderung – keine Hardwareanforderung. Das zeitnahe Reagieren auf Meldungen und die kontinuierliche Überwachung auf Schwachstellen sind Empfehlungen.

Bestimmung 3: Software aktuell halten

Geräte müssen über einen sicheren Update-Mechanismus verfügen, sofern dem keine Ressourcenbeschränkung des Anwendungsfalls entgegensteht, und:

• Update-Prozesse müssen für den Benutzer einfach sein (kein Fachwissen erfordern)
• Über ein Netzwerk bereitgestellte Updates müssen auf Authentizität und Integrität geprüft werden
• Updates müssen zeitnah erfolgen – kritische Schwachstellen müssen umgehend behoben werden
• Der Hersteller muss den definierten Support-Zeitraum veröffentlichen
• Die Benachrichtigung des Benutzers, dass ein Sicherheitsupdate erforderlich ist, ist eine Empfehlung

Auswirkungen auf die Hardware: Der Standard schreibt weder eine OTA-Bereitstellung noch einen Rollback-Schutz vor; er nennt eine Anti-Rollback-Richtlinie auf Basis einer Versionsprüfung lediglich als Beispiel. Ein Rollback-Schutz ist dennoch gute Praxis. Wenn der MCU keinen Anti-Rollback-Schutz implementieren kann (z. B. über monotone Zähler im sicheren Speicher), werden Firmware-Downgrade-Angriffe möglich.

Bestimmung 4: Sensible Sicherheitsparameter sicher speichern

Anmeldedaten, kryptografische Schlüssel und andere sensible Parameter müssen mit angemessenem Schutz gespeichert werden. Hartcodierte Anmeldedaten in der Firmware sind verboten.

Auswirkungen auf die Hardware: Sensible Parameter sollten in hardwaregeschütztem Speicher abgelegt werden (Secure Element, durch TrustZone geschützter Speicher, durch eFuse gesperrte Bereiche). Eine rein softwarebasierte Speicherung im Standard-Flash-Speicher ist für Anwendungsfälle mit hohen Sicherheitsanforderungen unzureichend.

Bestimmung 5: Sicher kommunizieren

Das Gerät muss für die sichere Kommunikation Kryptografie nach bewährten Verfahren (Best Practice) verwenden; der Standard nennt bewusst keine Protokolle oder Versionen. Darüber hinaus:

• Geschützte Geheimnisse – kritische Sicherheitsparameter, die über per Fernzugriff erreichbare Schnittstellen übertragen werden, müssen in ihrer Vertraulichkeit geschützt sein
• Authentifizierte Konfiguration – sicherheitsrelevante Konfigurationsänderungen über ein Netzwerk müssen eine Authentifizierung erfordern
• Empfohlen – Authentifizierung vor jedem Netzwerkzugriff auf Gerätefunktionen

Der Standard selbst legt keine TLS-Version fest: Veraltete Protokolle (SSLv3, TLS 1.0, WEP, WPA) entsprechen nicht den bewährten Verfahren, und TLS 1.2 oder höher (bevorzugt TLS 1.3) ist die übliche Auslegung für die Internetkommunikation – eine Interpretation, kein Normtext.

Bestimmung 6: Exponierte Angriffsflächen minimieren

Das Gerät sollte nur das exponieren, was für seine beabsichtigte Funktionalität erforderlich ist:

• Unbenutzte Netzwerkschnittstellen und über das Netzwerk zugängliche logische Schnittstellen müssen deaktiviert sein
• Debug-Schnittstellen (JTAG, SWD, UART) müssen deaktiviert oder durch Authentifizierung oder Zugriffskontrolle geschützt sein
• Nur benötigte Softwaredienste zu aktivieren und Software mit den geringstmöglichen Berechtigungen auszuführen, sind Empfehlungen

Auswirkungen auf die Hardware: Physische Debug-Schnittstellen (JTAG, SWD) sollten durch OTP-Fuses gesperrt oder in Produktionsgeräten dauerhaft deaktiviert werden. Ein aktiviertes JTAG bei Produktionseinheiten ist ein häufiger Befund bei Sicherheitsaudits.

Bestimmung 7: Software-Integrität sicherstellen

Das Gerät sollte seine Software verifizieren und auf unbefugte Änderungen reagieren – die Bestimmungen dieser Gruppe sind Empfehlungen (SHOULD), keine verbindlichen Anforderungen:

• Secure Boot – das Gerät sollte seine Software mithilfe von Secure-Boot-Mechanismen verifizieren
• Update-Validierung – durch Bestimmung 3 abgedeckt (verbindlich für über ein Netzwerk bereitgestellte Updates)
• Wird eine unbefugte Softwareänderung erkannt, sollte das Gerät den Benutzer oder Administrator warnen

Auswirkungen auf die Hardware: Der Standard nennt einen Hardware-Vertrauensanker (Root of Trust) als eine Möglichkeit, Secure Boot zu unterstützen; er schreibt keinen vor. Eine vollständige Secure-Boot-Kette vom Boot-ROM bis zur Anwendungs-Firmware, die in der Hardware verankert ist (in OTP-Fuse gespeicherter Root-Schlüssel), ist die robuste Umsetzung – rein softwarebasierte Integritätsprüfungen können umgangen werden.

Bestimmung 8: Sicherheit personenbezogener Daten gewährleisten

Diese Gruppe betrifft personenbezogene Daten bei der Übertragung und die Sensoren des Geräts:

• Sensible personenbezogene Daten, die an zugehörige Dienste übertragen werden, müssen durch Kryptografie nach bewährten Verfahren in ihrer Vertraulichkeit geschützt sein (für andere personenbezogene Daten empfohlen)
• Alle externen Sensorfunktionen (z. B. optische oder akustische Sensoren) müssen für den Benutzer klar dokumentiert sein

Einwilligung und Transparenz werden durch die gesonderten Datenschutzbestimmungen (Abschnitt 6) abgedeckt, das Löschen von Benutzerdaten durch Bestimmung 11.

Bestimmung 9: Systeme widerstandsfähig gegen Ausfälle machen

Geräte sollten bei Verlust des Netzwerkzugangs in Betrieb und lokal funktionsfähig bleiben und sollten:

• nach einem Stromausfall bei Wiederkehr der Stromversorgung sauber wieder anlaufen
• sich geordnet wieder mit Netzwerken verbinden

Bestimmung 10: System-Telemetriedaten untersuchen

Werden Telemetriedaten von Geräten erhoben, sollten sie auf Sicherheitsanomalien untersucht werden. Dies ist eine Empfehlung (SHOULD), keine verbindliche Anforderung (SHALL).

Bestimmung 11: Benutzern das Löschen personenbezogener Daten erleichtern

Geräte müssen Benutzern eine einfache Möglichkeit bieten, ihre Benutzerdaten vom Gerät zu löschen (verbindlich). Das Löschen personenbezogener Daten aus zugehörigen Diensten, klare Anleitungen und eine Bestätigung der Löschung sind Empfehlungen.

Bestimmung 12: Installation und Wartung einfach gestalten

Einrichtungs- und Wartungsprozesse sollten vom Benutzer kein spezielles Sicherheitswissen erfordern. Sicherheit sollte standardmäßig („by default“) gegeben sein und keine Konfiguration durch den Benutzer erfordern, um aktiv zu sein.

Bestimmung 13: Eingabedaten validieren

Geräte müssen Daten validieren, die über Benutzeroberflächen und über Netzwerkschnittstellen, einschließlich APIs, eingegeben werden, um Manipulationen und Ausfälle, etwa durch Injection-Angriffe, zu verhindern (verbindlich).

EN 303 645 und EN 18031: Beziehung und Unterschiede

Eine häufige Quelle der Verwirrung ist die Beziehung zwischen der EN 303 645 und der neueren Normenreihe EN 18031:

Praktischer Hinweis: Für Funkanlagen im Anwendungsbereich des delegierten Rechtsakts zur RED ist die EN 18031 die harmonisierte Normenreihe, deren Fundstelle im Amtsblatt veröffentlicht ist; ihre Anwendung ist freiwillig, und die Konformitätsvermutung gilt vorbehaltlich der veröffentlichten Einschränkungen. Die EN 303 645 begründet keine Konformitätsvermutung nach der RED, bleibt aber als Grundlage, für die Konformität auf dem britischen Markt und für darauf aufbauende Kennzeichnungssysteme nützlich.

EN 303 645 und nationale/internationale Regelungen

Die EN 303 645 wurde als technische Grundlage für mehrere nationale Regelungen für Consumer-IoT herangezogen:

Ein Produkt, das die Konformität mit EN 303 645 erreicht, verfügt über eine starke Grundlage für die Cybersicherheitsanforderungen mehrerer nationaler Märkte – was die Norm zu einem De-facto-Standard für den globalen Markt macht.

Konformitätsprüfung: ETSI TS 103 701

Die ETSI TS 103 701 ist die begleitende Testspezifikation zur EN 303 645. Sie bietet:

• Spezifische Testfälle für jede Bestimmung
• Definierte Testmethoden (Black-Box, White-Box, Dokumentationsprüfung)
• Erfolgs-/Fehlschlagskriterien für jede Anforderung

Zugelassene Prüflabore verwenden die TS 103 701, um strukturierte Prüfberichte zu erstellen, die als Nachweis in der technischen Dokumentation für die Einhaltung gesetzlicher Vorschriften dienen.

Zusammenfassung der Auswirkungen auf die Hardware

Aus unserer Erfahrung

Bei der Durchführung von Gap-Analysen nach EN 303 645 für IoT-Produkte für Verbraucher beobachten wir immer wieder die folgenden Muster:

Bestimmung 1 wird bei etwa 60 % der Erstbewertungen nicht erfüllt. Obwohl es sich um die bekannteste Anforderung der EN 303 645 handelt, bleiben gemeinsam genutzte Standard-Anmeldedaten die häufigste Nichtkonformität, die wir feststellen. Die Anmeldedaten sind oft nicht admin/admin – dessen sind sich die Hersteller bewusst –, sondern ein vom Gerätemodell abgeleitetes Standardpasswort (z. B. die letzten 4 Ziffern einer MAC-Adresse), das algorithmisch vorhersagbar ist. Die ETSI TS 103 701 prüft explizit auf vorhersagbare gerätespezifische Anmeldedaten, nicht nur auf universelle. Die Behebung erfordert sowohl eine Änderung bei der Provisionierung auf Hardware-Ebene (einzigartige Anmeldedaten, die bei der Fertigung mit einem HSM generiert und injiziert werden) als auch eine Änderung des Produktionsprozesses. Wir empfehlen, dies als eine Aufgabe des Fertigungs-Engineerings und nicht als eine Firmware-Aufgabe zu behandeln.

Bestimmung 6 JTAG-Entdeckung: der häufigste Befund bei Sicherheitsaudits. Bei über 80 % der Hardware-Sicherheitsbewertungen, bei denen wir Produktionseinheiten (keine Entwicklungsmuster) erhalten, ist der JTAG- oder SWD-Debug-Zugang noch aktiv. Hersteller testen typischerweise mit Entwicklungsmustern, bei denen JTAG absichtlich aktiviert ist, und der Produktions-Firmware-Build enthält das Brennen der OTP-Fuse nicht als letzten Fertigungsschritt. Das Ergebnis ist ein Produktionsgerät, bei dem jeder Angreifer mit einer 30-€-Debug-Sonde den gesamten Flash-Speicher auslesen, Anmeldedaten extrahieren, den Secure Boot umgehen und beliebige Firmware installieren kann. Wir implementieren einen obligatorischen Verifizierungsschritt für gesperrtes JTAG in den Produktionstestvorrichtungen: Jede Einheit, die nach dem Programmierschritt in der Produktion auf einen JTAG-Verbindungsversuch reagiert, wird aussortiert.

Bestimmung 3 Anti-Rollback: häufig behauptet, selten korrekt implementiert. Viele Hersteller geben an, dass ihr OTA-Update-System ein Firmware-Downgrade verhindert. In der Praxis stellen wir fest, dass dies als Software-Versionsprüfung in der Anwendungs-Firmware implementiert ist – was von jedem Angreifer, der das Gerät bereits kompromittiert hat, trivial umgangen werden kann. Die EN 303 645 selbst verlangt keinen Anti-Rollback-Schutz – sie nennt eine Richtlinie auf Basis einer Versionsprüfung lediglich als Beispiel –, doch aus unserer Sicht erfordert ein robuster Anti-Rollback-Schutz einen monotonen Hardware-Zähler in einem manipulationsresistenten Speicherbereich, der nicht dekrementiert werden kann. Auf Geräten ohne Secure Element oder TrustZone-fähigen SoC ist dies architektonisch unmöglich, rein in Software korrekt zu implementieren. Die Auswahl eines Chipsatzes, der Anti-Rollback hardwareseitig unterstützt, muss eine Designentscheidung des ersten Tages sein.

Bestimmung 5 TLS 1.0/1.1 Legacy-Backend-Verbindungen. Ein Produkt kann TLS 1.3 auf dem Gerät unterstützen – und dennoch einen Befund zu Bestimmung 5 auslösen, wenn es ein Downgrade auf TLS 1.0 oder 1.1 akzeptiert, weil das Cloud-Backend, mit dem es sich verbindet, diese Versionen für ältere Clients weiterhin anbietet. Die EN 303 645 selbst definiert keine Tests; die begleitende ETSI TS 103 701 prüft die vom Gerät tatsächlich verwendete Kryptografie gegen die Angaben des Herstellers. Wir finden dies am häufigsten bei Produkten, die sich mit bestehenden Unternehmens-Backends verbinden, die nicht aktualisiert wurden, als die Geräte-Firmware auf TLS 1.2+ umgestellt wurde. Die Lösung besteht darin, veraltete Versionen im Backend nicht mehr anzubieten und sie vom Gerät ablehnen zu lassen – und die Backend-Seite liegt oft außerhalb der direkten Kontrolle des Hardwareherstellers, wenn eine gemeinsam genutzte Cloud-Plattform verwendet wird.

Verwandte Begriffe

• EN 18031 – Die harmonisierte Normenreihe, deren Fundstelle für den delegierten Rechtsakt zur RED veröffentlicht ist; ein eigenständiges Werk von CEN-CENELEC, keine Neuausgabe der EN 303 645.
• Delegierter Rechtsakt zur RED – Das Rechtsinstrument, das die Cybersicherheitsanforderungen nach Artikel 3(3)(d), (e) und (f) der RED ab dem 1. August 2025 für bestimmte Kategorien von Funkanlagen anwendbar gemacht hat; es schreibt keine bestimmte Norm vor.
• CRA – Cyberresilienz-Verordnung der EU; sie verweist nicht auf die EN 303 645 – ihre harmonisierten Normen werden gesondert von CEN, CENELEC und ETSI erarbeitet.
• Secure Boot – Durch Bestimmung 7 empfohlen (ein SHOULD, keine verbindliche Anforderung).
• OTA-Update – Bestimmung 3 verlangt einen sicheren Update-Mechanismus und die Prüfung von über ein Netzwerk bereitgestellten Updates; Anti-Rollback erscheint nur als Beispiel.
• Hardware-Vertrauensanker (Root of Trust) – Untermauert die Bestimmungen 4 und 7.

Offizielle Quellen

• ETSI EN 303 645 V3.1.3 – kostenloser Download (etsi.org)
• ETSI TS 103 701 V2.1.1 – Spezifikation zur Konformitätsbewertung nach EN 303 645 (kostenloser Download)
• Delegierter Rechtsakt zur RED (EU) 2022/30 – EUR-Lex
• ETSI releases world-leading Consumer IoT Security standard – ETSI-Pressemitteilung (Juni 2020)

Die Konformität mit EN 303 645 wird zunehmend zu einer grundlegenden Erwartung für vernetzte Hardwareprodukte, die auf den EU-, britischen und globalen Märkten eingeführt werden. Inovasense führt Gap-Analysen zu allen 13 Bestimmungen der EN 303 645 durch – wir gleichen bestehende Hardwarefähigkeiten mit jeder SHALL-Anforderung ab, identifizieren notwendige Änderungen an Hardware oder Produktionsprozessen (Provisionierung, Sperrung von Debug-Ports, sicherer Speicher) und erstellen testreife Dokumentationen für die Einreichung bei einem zugelassenen Labor. Sehen Sie sich unsere Expertise im Bereich Embedded Security und unsere Dienstleistungen zur EU-Konformität an.