# MQTT-Sicherheit: Checkliste für vernetzte Produkte

MQTT-Sicherheitscheckliste für IoT-Hersteller: Authentifizierung, TLS, Topic-Autorisierung, Zugangsdaten pro Gerät und Broker-Härtung, mit den häufigsten Fehlern.

Source: https://zyberum.com/de/insights/mqtt-sicherheit-checkliste · Updated: 2026-10-07

Wenn dein Produkt mit einem Cloud-Backend spricht, stehen die Chancen gut, dass MQTT die Nachrichten transportiert, und dass der Broker der schwächste Teil des Systems ist. MQTT ist ein leichtgewichtiges Publish-Subscribe-Protokoll: Geräte publizieren auf Topics und abonnieren Topics, und ein Broker vermittelt dazwischen. Das Protokoll selbst tut für die Sicherheit fast nichts, also hängt die Sicherheit der ganzen Flotte daran, wie der Broker konfiguriert ist und wie die Anwendung ihn nutzt. Diese Checkliste arbeiten wir in jedem IoT-Test ab, der einen Broker einschließt.

## Der eine Fehler, der alles aufbricht

Das schädlichste MQTT-Finding ist die fehlende Topic-Autorisierung. Ein Broker prüft, dass sich ein Client authentifiziert hat, und lässt diesen Client dann jedes Topic abonnieren, nach dem er fragt. Weil Geräte meist auf vorhersehbare Topics publizieren (`device/{id}/telemetry`, `device/{id}/command`), kann ein gültiges Konto, oft aus der Firmware eines einzigen Geräts gewonnen, die Daten jedes anderen Geräts abonnieren und ihnen Kommandos schicken. Wir haben einen einzigen Satz extrahierter Broker-Zugangsdaten an einem Nachmittag in vollen Lese- und Schreibzugriff auf eine ganze Flotte verwandelt. Zugangsdaten pro Gerät helfen hier nur, wenn der Broker jedes Gerät zusätzlich auf seine eigenen Topics beschränkt.

## Die Checkliste

Arbeite von oben nach unten. Jeder Punkt ist etwas, das wir aktiv testen.

### Authentifizierung
- [ ] Jeder Client authentifiziert sich. Anonyme Verbindungen sind am Broker abgeschaltet.
- [ ] Zugangsdaten gelten **pro Gerät**, nicht ein geteiltes Konto, das in jede Einheit gebrannt ist.
- [ ] Geräte-Zugangsdaten werden bereitgestellt, nicht im Firmware-Image ausgeliefert, und lassen sich rotieren und widerrufen.
- [ ] Wo die Hardware es unterstützt, nutzen Geräte **Client-Zertifikate** (mutual TLS) statt Passwörter.

### Transport
- [ ] TLS wird erzwungen (Port 8883). Klartext (1883) ist geschlossen oder nur an localhost gebunden.
- [ ] Das Gerät **prüft das Broker-Zertifikat**. Ein Gerät, das jedes Zertifikat akzeptiert, ist offen für einen Machine-in-the-Middle, und das testen wir direkt.
- [ ] Nur TLS 1.2 oder 1.3, moderne Cipher Suites, Zertifikats-Pinning, wo der Update-Prozess es zulässt.

### Autorisierung
- [ ] Jedes Gerät darf **nur auf seinen eigenen Topics** publizieren und abonnieren. Das ist eine Zugriffsliste am Broker, erzwungen pro Client.
- [ ] Wildcard-Abonnements (`#`, `+`) stehen Geräte-Konten nicht zur Verfügung.
- [ ] Kommando-Topics sind nur vom Backend beschreibbar, nicht von anderen Geräten.

### Broker-Härtung
- [ ] Der Broker ist gepatcht und gibt seine Admin- oder Metrik-Schnittstelle nicht ins Internet frei.
- [ ] Standardkonten sind entfernt. Viele Broker liefern einen bekannten Testbenutzer aus.
- [ ] Nachrichtengröße, Verbindungsrate und Abonnementzahl sind begrenzt, damit ein Client den Broker nicht erschöpft.
- [ ] Logging ist aktiv, und fehlgeschlagene Authentifizierungen und ungewöhnliche Abonnements sind für dein Monitoring sichtbar.

### Anwendungsdesign
- [ ] Keine Geheimnisse, personenbezogenen Daten oder Kommando-Token stehen in Klartext-Topic-Namen oder in Retained Messages.
- [ ] Retained Messages und Last-Will-Payloads sind geprüft, denn solche Nachrichten geben oft Zustand an jeden Abonnenten preis.
- [ ] Das Backend validiert Payloads. Ein Gerät darf keine fehlerhafte Nachricht senden können, die den Verbraucher abstürzen lässt.

## Was wir in der Praxis sehen

Über IoT-Pentests von ESP32-basierten Modulen, Broker-Setups und den dahinterliegenden Cloud-APIs hinweg kommen dieselben wenigen Probleme auf. Anonymer Zugriff zum Testen aktiv gelassen. Ein geteiltes Konto für die ganze Produktlinie, aus dem Flash jeder Einheit wiederherstellbar. TLS vorhanden, aber das Gerät prüft das Zertifikat nicht, sodass ein lokaler Angreifer sich dazwischensetzen kann. Und, am häufigsten, gar keine Topic-Autorisierung, sodass jedes authentifizierte Gerät jedes andere sieht. Nichts davon ist exotisch. Es sind Konfigurations-Standardwerte, die vor der Auslieferung nie geändert wurden.

## Wie das auf Compliance abbildet

Für Produkte im Anwendungsbereich des Cyber Resilience Act verlangt Anhang I den Schutz von Vertraulichkeit und Integrität der Daten und der Kommunikation. Ein MQTT-Broker, der ein Gerät die Daten eines anderen lesen lässt, ist eine direkte Lücke gegen diese Anforderung. Für vernetzte Funkanlagen weist EN 18031 in dieselbe Richtung bei Netzwerkkommunikation und Zugriffskontrolle. Ein Review der Broker-Konfiguration und ein IoT-Pentest liefern dir den Nachweis, dass die Maßnahmen wirken.

## Womit du anfängst

Repariere zuerst die Topic-Autorisierung: Das schließt die flottenweite Offenlegung, die alles andere erst ermöglicht. Dann erzwinge TLS mit Zertifikatsprüfung auf dem Gerät, wechsle zu Zugangsdaten pro Gerät und härte den Broker. Zyberum testet Broker, Geräte und die dahinterliegenden Cloud-APIs mit schriftlicher Erlaubnis und testet kein System ohne sie. Mehr dazu unter [IoT-Sicherheit](/de/iot-security), oder buch ein [kostenloses Erstgespräch](/de/kontakt?meeting=intro).

## FAQ

**Hat MQTT eingebaute Sicherheit?**

Kaum. Die MQTT-Spezifikation definiert ein Feld für Benutzername und Passwort und überlässt die Transportsicherheit dem darunterliegenden TLS, definiert aber keine eigene Verschlüsselung und kein eigenes Autorisierungsmodell. Alles jenseits eines Klartext-Passworts ist Sache der Broker-Konfiguration und des Anwendungsdesigns, und genau dort finden wir die meisten Probleme.

**Reichen Benutzername und Passwort für einen MQTT-Broker?**

Nein. Ein Passwort belegt nur, wer sich verbunden hat. Ohne Autorisierung pro Topic kann ein authentifizierter Client meist die Topics aller anderen Geräte abonnieren, und das ist das häufigste MQTT-Finding. Du brauchst Authentifizierung, TLS und Autorisierung auf Topic-Ebene zusammen.

**Sollte MQTT jemals ohne TLS aus dem Internet erreichbar sein?**

Nein. Port 1883 ist Klartext. Ist der Broker über 1883 aus dem Internet erreichbar, laufen Zugangsdaten und die gesamte Telemetrie im Klartext. Nutze TLS (Port 8883) und, wo möglich, Client-Zertifikate für die Geräte.

## Sources

- [OASIS: MQTT Version 5.0 Specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
- [OASIS: MQTT Version 3.1.1 Specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html)
- [OWASP Internet of Things Top 10 (2018)](https://owasp.org/www-project-internet-of-things/)
- [IETF RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446)

## Related

- [MQTT](https://zyberum.com/de/glossar/mqtt)
- [IoT-Penetrationstest: Was wir angreifen und was wir finden](https://zyberum.com/de/insights/iot-penetrationstest-erklaert)
- [Firmware-Extraktion: Was sie verrät und wie du sie verhinderst](https://zyberum.com/de/insights/firmware-extraktion-anleitung)
- [Angriffsfläche](https://zyberum.com/de/glossar/angriffsflaeche)
- [Vernetzte Produkte, die ein Leben lang sicher bleiben.](https://zyberum.com/de/iot-security)
- [Wir öffnen das Gehäuse. Dann die Firmware.](https://zyberum.com/de/hardware-pentest)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/insights/mqtt-sicherheit-checkliste