EU Cyber Resilience Act IoT: Was er für MQTT bedeutet

Der EU Cyber Resilience Act (CRA) verändert, wie vernetzte Produkte in der Europäischen Union entwickelt, ausgeliefert und gewartet werden. Dieser Artikel fasst zusammen, was der EU Cyber Resilience Act für IoT-Hersteller bedeutet, deren Geräte über MQTT kommunizieren: sichere Voreinstellungen, Updates, Umgang mit Schwachstellen und Dokumentation. Außerdem zeigt er, welche technischen Entscheidungen in Ihrer Messaging-Schicht diese Arbeit unterstützen. Es handelt sich um einen technischen Überblick, nicht um Rechtsberatung; klären Sie Ihre Pflichten mit qualifizierter Rechtsberatung und dem offiziellen Text.

Was der Cyber Resilience Act ist

Der CRA ist eine EU-Verordnung, die horizontale Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ stellt, also an Hardware- und Softwareprodukte, deren bestimmungsgemäße Verwendung eine Datenverbindung zu einem Gerät oder Netzwerk umfasst. Sie ist im Dezember 2024 in Kraft getreten, und ihre Pflichten gelten gestaffelt: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle ab September 2026, die meisten übrigen Pflichten ab Dezember 2027.

Für IoT-Teams ist vor allem der Anwendungsbereich wichtig. Ein Sensor, Gateway, smartes Haushaltsgerät oder eine industrielle Steuerung, die sich mit einem Netzwerk verbindet und auf dem EU-Markt bereitgestellt wird, fällt sehr wahrscheinlich in den Anwendungsbereich, ebenso wie ihre Firmware und die enthaltenen Softwarekomponenten. Einige Sektoren mit eigenen Regeln, etwa bestimmte Medizin- und Automobilprodukte, werden anders behandelt.

Für den Maschinen- und Anlagenbau im DACH-Raum ist das besonders relevant: Eine Maschine mit vernetzter Steuerung, einem Edge-Gateway oder einem MQTT-Modul für Industrie-4.0-Dienste wie Fernwartung, Predictive Maintenance oder Energiemonitoring bringt digitale Elemente mit, die unter den CRA fallen können. Der CRA regelt dabei das Produkt, während NIS2 die Betreiber wesentlicher und wichtiger Einrichtungen in die Pflicht nimmt; viele Mittelständler sind von beiden Seiten betroffen, als Hersteller und als Betreiber. Für industrielle Komponenten ist die Normenreihe IEC 62443 ein naheliegender technischer Bezugsrahmen, um Anforderungen an Zugriffskontrolle, Segmentierung und sichere Kommunikation zu strukturieren.

Produkte werden in Kategorien eingeteilt. Die meisten fallen in eine Standardkategorie, in der Hersteller die Konformität selbst bewerten können. Produkte, die als „wichtig“ oder „kritisch“ eingestuft sind, unterliegen strengeren Bewertungsverfahren. Die Kategorie Ihres Geräts bestimmt, wie stark Dritte einbezogen werden müssen.

Kernpflichten für Hersteller

Die grundlegenden Anforderungen der Verordnung lassen sich in zwei Gruppen einteilen: Eigenschaften des Produkts und Prozesse für den Umgang mit Schwachstellen. Vereinfacht für das IoT:

Bereich	Was der CRA erwartet (vereinfacht)	Was das für ein MQTT-Gerät bedeutet
Secure by Default	Produkte werden mit sicherer Konfiguration und ohne bekannte ausnutzbare Schwachstellen ausgeliefert	Keine Standardpasswörter, TLS standardmäßig aktiv, keine Debug-Topics aktiviert
Zugriffskontrolle	Schutz vor unbefugtem Zugriff durch geeignete Authentifizierung und Identitätsverwaltung	Eindeutige Zugangsdaten pro Gerät, keine anonymen Broker-Verbindungen
Vertraulichkeit	Gespeicherte und übertragene Daten schützen, zum Beispiel durch Verschlüsselung	MQTT über TLS, geschützte Speicherung von Zugangsdaten
Integrität	Daten, Befehle und Firmware vor unbefugter Änderung schützen	Signierte Firmware, validierte Befehle
Datenminimierung	Nur die für den vorgesehenen Zweck nötigen Daten verarbeiten	Publizieren, was der Anwendungsfall braucht, nicht mehr
Verfügbarkeit und Resilienz	Wesentliche Funktionen aufrechterhalten, auch bei Denial-of-Service-Bedingungen	Backoff, Pufferung, korrektes Verhalten bei Broker-Limits
Angriffsfläche begrenzen	Exponierte Schnittstellen minimieren	Keine eingehenden Ports; nur ausgehendes MQTT
Sicherheitsupdates	Updates für den Supportzeitraum bereitstellen, idealerweise automatisch und getrennt von Funktionsupdates	Ein sicherer OTA-Pfad, der über Ihre Konnektivität funktioniert
Umgang mit Schwachstellen	Schwachstellen identifizieren, dokumentieren und beheben; Richtlinie zur koordinierten Offenlegung	SBOM inklusive MQTT-Bibliotheken, Kontakt für Meldungen, Patch-Prozess
Meldepflichten	Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle innerhalb festgelegter Fristen melden	Ein interner Prozess zum Erkennen, Bewerten und Melden
Dokumentation	Technische Dokumentation, Benutzerinformationen, Supportzeitraum	Dokumentieren, wie das Gerät sich verbindet und wie Nutzer es absichern

Sichere Voreinstellungen in der MQTT-Schicht

Viele historische IoT-Probleme gingen auf unsichere Voreinstellungen zurück. In MQTT-Begriffen übersetzt sich die Stoßrichtung des CRA in konkrete Designentscheidungen:

Keine geteilten oder voreingestellten Zugangsdaten. Jedes Gerät erhält bei Fertigung oder Onboarding eindeutige Zugangsdaten. Siehe sicheres Provisioning von IoT-Geräten.
TLS standardmäßig aktiv, mit Zertifikatsprüfung. Kein „unsicherer“ Modus in der Produktions-Firmware.
Nur ausgehende Verbindungen. Das Gerät baut eine Verbindung zum Broker auf; es lauscht nicht auf eingehendes MQTT.
Keine öffentlichen Broker für echte Daten. Ein öffentlicher MQTT-Broker ist für Tests und Prototypen in der Entwicklung nützlich, aber Produktions-Firmware muss sich mit einem privaten, authentifizierten Broker verbinden.
Minimale Topics. Publizieren Sie keine Diagnose-Dumps, Zugangsdaten oder unnötigen personenbezogenen Daten. In einem Unified Namespace (UNS), dessen Topic-Struktur der ISA-95-Hierarchie von Werk, Bereich, Linie und Zelle folgt, lassen sich Berechtigungen zudem pro Zweig vergeben, sodass jedes Gerät nur seinen eigenen Teil des Baums beschreiben darf.
Sichere Befehlsverarbeitung. Prüfen Sie jeden Befehl gegen eine Allowlist, bevor Sie ihn ausführen.

So sieht das in ESP32-Firmware mit WiFiClientSecure und PubSubClient aus:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

// ISRG Root X1 (Let's-Encrypt-Root) im PEM-Format, zur Verifizierung des Brokers
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Eindeutig pro Gerät, in der Produktion aus geschütztem Speicher geladen
extern const char* DEVICE_CLIENT_ID;  // YOUR_CLIENT_ID
extern const char* DEVICE_USERNAME;   // YOUR_USERNAME
extern const char* DEVICE_PASSWORD;   // YOUR_PASSWORD

WiFiClientSecure net;
PubSubClient mqtt(net);
unsigned long nextAttempt = 0;
unsigned long backoffMs = 1000;

void connectMqtt() {
  if (mqtt.connected() || millis() < nextAttempt) return;
  if (mqtt.connect(DEVICE_CLIENT_ID, DEVICE_USERNAME, DEVICE_PASSWORD)) {
    backoffMs = 1000;
  } else {
    nextAttempt = millis() + backoffMs + random(0, 1000);  // Backoff mit Jitter
    backoffMs = min(backoffMs * 2, 300000UL);
  }
}

void setup() {
  WiFi.begin("YOUR_WIFI_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);
  net.setCACert(ROOT_CA);               // Server prüfen; niemals setInsecure() aufrufen
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  connectMqtt();
  mqtt.loop();
}

Die für sichere Voreinstellungen entscheidenden Details sind sichtbar: Zertifikatsprüfung aktiv, keine fest im Sketch codierten Zugangsdaten und eine Reconnect-Strategie, die den Broker nicht überlastet. Das ESP32-MQTT-Tutorial zeigt die vollständige Publish-Schleife.

Updates und Umgang mit Schwachstellen

Der CRA legt großes Gewicht darauf, was nach der Auslieferung eines Produkts passiert. Bei MQTT-Geräten ist die Konnektivitätsschicht Teil davon:

Kennen Sie Ihre Komponenten. Pflegen Sie eine Software Bill of Materials (SBOM) mit Ihrer MQTT-Client-Bibliothek, Ihrer TLS-Bibliothek und deren Versionen. Erscheint ein Advisory, müssen Sie innerhalb von Stunden wissen, welche Produkte den betroffenen Code nutzen.
Halten Sie einen Update-Kanal bereit. Viele Teams signalisieren per MQTT, dass ein Update verfügbar ist, und laden ein signiertes Image per HTTPS herunter. Unabhängig vom Mechanismus muss er authentifiziert und integritätsgeschützt sein.
Trennen Sie Sicherheitsupdates. Liefern Sie Sicherheitskorrekturen nach Möglichkeit unabhängig von Funktionsreleases aus.
Veröffentlichen Sie eine Offenlegungsrichtlinie. Geben Sie Sicherheitsforschern einen klaren Weg, Probleme zu melden.
Bereiten Sie die Meldung vor. Legen Sie fest, wer Schwachstellen und Vorfälle bewertet und wie Meldungen innerhalb der vorgeschriebenen Fristen die Behörden erreichen.

Der Überblick über häufige MQTT-Schwachstellen ist ein guter Ausgangspunkt dafür, was Sie bei Client-Bibliotheken verfolgen sollten.

Wo der Broker ins Bild passt

Der CRA nimmt den Hersteller des Produkts in die Pflicht. Die Wahl eines bestimmten Brokers macht ein Produkt nicht konform, und kein Broker-Anbieter kann diese Verantwortung übernehmen. Was das Backend leisten kann: sichere Designs leichter umsetzbar und dokumentierbar machen.

ConnectMQ bietet Funktionen, auf die Sie in Ihrer technischen Dokumentation im Rahmen Ihrer eigenen Risikobewertung verweisen können:

MQTT über TLS auf 8883 und Secure WebSockets auf 8084 mit einem Let's-Encrypt-Zertifikat, sodass Geräte den Server mit einer Standard-Root verifizieren können.
Authentifizierte private Broker mit generierten Zugangsdaten und an diese Zugangsdaten gebundenen Client IDs.
Mandantenisolation, ein isolierter Cluster in Dedicated-Plänen oder das Deployment in Ihr eigenes Cloud-Konto mit BYOC.
Quotas pro Plan, signalisiert mit dem MQTT-5-Reason-Code 0x97, Flood Protection und IP-Sperren nach wiederholten fehlgeschlagenen Logins, die die Verfügbarkeit bei Missbrauch unterstützen.
Verbindungsstatus über $SYS/broker/connection/{clientId}/state und Schwellenwert-Alarme im Portal, die helfen, auffälliges Verhalten zu erkennen.

Beschreiben Sie ConnectMQ oder einen anderen Broker nicht als CRA-Compliance-Lösung. Dokumentieren Sie ihn als Komponente Ihrer Architektur, listen Sie seine Sicherheitseigenschaften auf und behalten Sie die Verantwortung für die geräteseitigen Kontrollen. Der Leitfaden zum verwalteten MQTT-Broker erklärt die Aufteilung der geteilten Verantwortung.

Eine praktische CRA-Readiness-Checkliste für MQTT-Geräte

Prüfen Sie, ob Ihr Produkt in den Anwendungsbereich fällt und welche Kategorie gilt.
Führen Sie eine Cybersicherheits-Risikobewertung durch, die die MQTT-Datenflüsse abdeckt, und dokumentieren Sie sie.
Entfernen Sie voreingestellte und geteilte Zugangsdaten; stellen Sie eindeutige Identitäten pro Gerät bereit.
Erzwingen Sie TLS mit Prüfung des Serverzertifikats in der Produktions-Firmware.
Stellen Sie sicher, dass Geräte nur ausgehende Verbindungen aufbauen und keine unnötigen Schnittstellen bereitstellen.
Validieren Sie alle empfangenen Befehle und begrenzen Sie, was sie ändern können.
Implementieren Sie Reconnect-Backoff und Offline-Pufferung für mehr Resilienz.
Pflegen Sie eine SBOM inklusive MQTT- und TLS-Bibliotheken.
Entwickeln und testen Sie einen signierten, authentifizierten Update-Mechanismus.
Veröffentlichen Sie eine Richtlinie zur Offenlegung von Schwachstellen und definieren Sie den Meldeprozess.
Legen Sie den Supportzeitraum fest und kommunizieren Sie ihn.
Erstellen Sie Benutzerdokumentation zur sicheren Einrichtung und Außerbetriebnahme.

Für den größeren Zusammenhang behandeln die Best Practices für MQTT-Sicherheit und Zero Trust für IoT-Messaging viele derselben Kontrollen aus technischer Sicht. Offizielle Leitlinien und der Verordnungstext werden von der Europäischen Kommission veröffentlicht.

Sichere Konnektivität mit ConnectMQ aufbauen

Beginnen Sie mit der Konnektivitätsschicht, während Sie den Rest der Checkliste abarbeiten. Erstellen Sie einen privaten Broker im kostenlosen Serverless-Plan unter app.connectmq.com (ohne Kreditkarte), verbinden Sie ein Entwicklungsgerät über TLS mit eindeutigen Zugangsdaten und nutzen Sie den öffentlichen MQTT-Broker nur für Tests und Wegwerf-Experimente. Wenn Sie Isolation benötigen, vergleicht der Leitfaden zum Cloud-MQTT-Broker die Deployment-Modelle.

Häufig gestellte Fragen

Gilt der Cyber Resilience Act für mein IoT-Gerät?

Wenn es sich um ein Produkt mit digitalen Elementen handelt, das sich mit einem Gerät oder Netzwerk verbindet und auf dem EU-Markt bereitgestellt wird, sehr wahrscheinlich ja, sofern es nicht durch sektorspezifische Regeln ausgenommen ist. Klären Sie Anwendungsbereich und Kategorie Ihres Produkts mit Ihrer Rechtsberatung.

Ab wann gelten die Pflichten des CRA?

Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten ab September 2026, die meisten übrigen Pflichten ab Dezember 2027.

Macht ein sicherer MQTT-Broker mein Produkt CRA-konform?

Nein. Die Konformität des gesamten Produkts liegt in der Verantwortung des Herstellers. Ein sicherer Broker unterstützt Ihr Design, aber Geräte-Firmware, Updates, Umgang mit Schwachstellen und Dokumentation bleiben Ihre Aufgabe.

Reicht MQTT über TLS, um die Vertraulichkeitsanforderung des CRA zu erfüllen?

TLS schützt Daten bei der Übertragung, was ein wichtiger Teil ist. Sie müssen dennoch gespeicherte Zugangsdaten und Daten auf dem Gerät schützen und bewerten, ob für Ihr Risikoprofil zusätzliche Maßnahmen nötig sind.

EU Cyber Resilience Act und IoT: Was er für MQTT-Geräte bedeutet