IoT-Systeme wirken erst dann einfach, wenn Geräte nur Daten senden. Sobald aber Provisionierung, Updates, digitale Zwillinge, Edge-Verarbeitung und Sicherheitsrichtlinien zusammenkommen, braucht es eine Plattform, die im Alltag nicht nur funktioniert, sondern auch beherrschbar bleibt. Genau darum geht es hier: um die beste IoT-Plattform im praktischen Sinn, also um Lösungen, die zu Gerätegröße, Betriebsmodell und Konnektivität wirklich passen.
Die Auswahl entscheidet sich an Betrieb, Skalierung und Edge-Fähigkeit
- AWS IoT Core und Azure IoT Hub sind stark, wenn du sehr große Flotten cloudnah und hochautomatisiert betreiben willst.
- Cumulocity, Siemens Insights Hub, Bosch IoT Suite und ThingWorx sind besonders interessant, wenn industrielle Assets, Wartung und Prozesskontext im Vordergrund stehen.
- ThingsBoard ist die spannendste offene Alternative, wenn du mehr Kontrolle über Betrieb, Hosting und Datenflüsse behalten möchtest.
- Die beste Wahl hängt weniger vom Markennamen ab als von Device-Lifecycle, Integrationstiefe, Offline-Fähigkeit und Sicherheitsmodell.
- Für verteilte Standorte, Telekommunikation und Infrastrukturprojekte ist Edge-Unterstützung oft wichtiger als die größte Feature-Liste.
- Google Cloud IoT Core gehört 2026 nicht mehr in eine ernsthafte Shortlist, weil der Dienst nicht mehr verfügbar ist.
Was eine starke IoT-Plattform heute leisten muss
Wenn ich IoT-Plattformen bewerte, prüfe ich zuerst nicht die Oberfläche, sondern den Gerätelebenszyklus. Eine gute Lösung muss Geräte sicher aufnehmen, identifizieren, konfigurieren, aktualisieren und wieder sauber aus dem Bestand entfernen können. Genau daran scheitern viele Pilotprojekte, weil sie nur den ersten Datenfluss zeigen, aber nicht den Betrieb über Monate und Jahre abbilden.
Für reale IoT-Systeme sind aus meiner Sicht sechs Punkte entscheidend:
| Kriterium | Warum es wichtig ist | Worauf ich achte |
|---|---|---|
| Geräteidentität und Onboarding | Ohne saubere Provisionierung wird jede Flotte unübersichtlich und unsicher. | Zertifikate, Bulk-Provisioning, Zero-touch-Setup, Rollenmodell. |
| Bidirektionale Kommunikation | IoT ist nicht nur Telemetrie, sondern auch Steuerung, Konfiguration und OTA-Update. | MQTT, HTTP, device twin oder shadow, zuverlässige Rückkanäle. |
| Edge- und Offline-Fähigkeit | Geräte an entfernten Standorten müssen auch bei Verbindungsproblemen weiterarbeiten. | Store-and-forward, lokale Regeln, Edge Runtime, Synchronisation nach Ausfall. |
| Digital Twin und Asset-Modell | Rohdaten reichen selten aus, erst Kontext macht sie operativ nutzbar. | Asset-Hierarchien, Beziehungen, Statusmodelle, klare Zuordnung von Geräten zu Anlagen. |
| Sicherheit und Governance | Je mehr Geräte du betreibst, desto teurer wird jedes Sicherheitsloch. | Verschlüsselung, Audit-Logs, Mandantentrennung, Schlüsselrotation, Zugriffskontrolle. |
| Integrationen und Betriebsfähigkeit | Die Plattform muss sich in bestehende Prozesse einfügen, nicht danebenstehen. | APIs, Event-Streaming, BI-Anbindung, Ticketing, Monitoring, Exportmöglichkeiten. |
Gerade bei verteilten Infrastrukturen, Außenstationen oder Netzen mit schwankender Bandbreite wird die Edge-Frage zum eigentlichen Taktgeber. Wer das am Anfang unterschätzt, landet schnell bei einer Plattform, die im Demo-Modus gut aussieht, im Betrieb aber zu viel manuelle Pflege verlangt. Im nächsten Schritt lohnt sich deshalb der direkte Marktvergleich, nicht als Namensliste, sondern als Entscheidungshilfe.
Welche Plattformen im direkten Vergleich vorne liegen
Die aktuelle Auswahl lässt sich grob in drei Gruppen teilen: Hyperscaler, industrielle Plattformen und offene beziehungsweise selbst betreibbare Lösungen. Jede Gruppe hat ihre Stärken, aber auch eine klare Grenze. Eine Plattform ist nicht deshalb gut, weil sie viele Features hat, sondern weil sie die richtige Art von Komplexität reduziert.
| Plattform | Stärken | Grenzen | Typisch passend für |
|---|---|---|---|
| AWS IoT Core | Sehr starke Skalierung, saubere MQTT-Basis, Device Shadow, tiefe Cloud-Integration. | Die Breite des AWS-Ökosystems kann Betrieb und Kosten schnell komplex machen. | Große Cloud-native Flotten, datengetriebene Produkte, stark automatisierte Backends. |
| Azure IoT Hub | Starke Device-Twin-Funktionen, Cloud-to-Edge-Ansatz, gute Einbindung in Microsoft-Stacks. | Wirkt am besten, wenn du ohnehin im Azure-Ökosystem arbeitest. | Unternehmen mit Microsoft-Infrastruktur, hybride Szenarien, Gerätemanagement in großem Maßstab. |
| Cumulocity | Starkes Device-Management, Digital-Twin-Ansatz, Self-Service-Charakter, guter Industriebezug. | Weniger frei als Open Source, dafür stärker vorstrukturiert und enterprise-orientiert. | Hersteller, Betreiber und Service-Teams mit Fokus auf operative Transparenz. |
| Siemens Insights Hub | Industrie- und Produktionsfokus, Asset-Kontext, gute Anbindung an Prozesse und Fertigung. | Besonders stark in industriellen Umgebungen, weniger universell für reine Consumer-IoT-Szenarien. | Fertigung, Maschinenbau, Prozessindustrie, OT-nahe IoT-Systeme. |
| Bosch IoT Suite | Device- und Datenmanagement, Edge-Bezug, digitale Zwillinge, private Cloud und On-Prem möglich. | Mehr Integrationsarbeit als bei einem reinen Hyperscaler-Standarddienst. | Verteilte Anlagen, Infrastruktur, serviceorientierte Device-Flotten, Datenhoheit. |
| ThingWorx | Starker IIoT-Fokus, guter Brückenschlag zwischen Maschinen, Daten und Anwendungen. | Am stärksten dort, wo industrielle Use Cases wirklich zentral sind. | Industrieprojekte, operative Dashboards, verknüpfte Produktions- und Serviceprozesse. |
| ThingsBoard | Open Source, cloud- und on-prem-fähig, gute Protokollabdeckung, flexibel im eigenen Betrieb. | Mehr Eigenverantwortung bei Betrieb, Skalierung und Architekturentscheidungen. | Teams mit Budgetdruck, Bedarf an Kontrolle und Wunsch nach selbstbestimmtem Hosting. |
Mein praktischer Eindruck ist klar: AWS und Azure gewinnen oft bei reiner Cloud-Skalierung, während Cumulocity, Siemens, Bosch und ThingWorx dort punkten, wo Anlagenkontext, Wartung und industrielle Integration wichtiger sind als die maximale Service-Breite. ThingsBoard bleibt interessant, wenn du eine offene Basis mit On-Prem-Option, flexibler Modellierung und weniger Herstellerbindung willst. Und Google Cloud IoT Core würde ich 2026 nicht mehr berücksichtigen, weil der Dienst beendet ist. Genau deshalb geht es im nächsten Abschnitt nicht um Produkte, sondern um passende Einsatzszenarien.
Welche Lösung zu welchem Einsatz passt
Die Frage nach der besten Plattform beantworte ich nie abstrakt, sondern immer aus Sicht des Einsatzes. Bei einem Sensorverbund in Gebäuden, einem verteilten Versorgungsnetz oder einer Anlage mit Mobilfunkanbindung zählen andere Dinge als bei einer zentralen Fabrikhalle mit stabiler LAN-Infrastruktur. Wer diese Unterschiede ignoriert, kauft eine Plattform für den falschen Betrieb.
| Einsatzszenario | Meine erste Wahl | Warum |
|---|---|---|
| Cloud-first mit sehr vielen Geräten | AWS IoT Core oder Azure IoT Hub | Skalierung, Automatisierung und Cloud-Integration stehen hier klar im Vordergrund. |
| Industrieanlage mit starkem Asset-Kontext | Siemens Insights Hub oder ThingWorx | Die Plattform muss Maschinen, Prozesse und Wartung sprachfähig machen, nicht nur Daten transportieren. |
| Verteilte Standorte mit schwankender Konnektivität | Bosch IoT Suite oder ThingsBoard | Edge- und On-Prem-Optionen helfen, wenn Verbindungen nicht immer stabil sind. |
| Managed Device Fleet für Hersteller oder Serviceanbieter | Cumulocity | Geräteverwaltung, digitale Zwillinge und betriebliche Transparenz greifen gut ineinander. |
| Budgetbewusste Teams mit Bedarf an Kontrolle | ThingsBoard | Open Source ist hier attraktiv, wenn das Team Betrieb und Architektur selbst tragen kann. |
| Unternehmen mit bestehendem Microsoft-Stack | Azure IoT Hub | Die Einbindung in Identität, Datenflüsse und Edge-Komponenten ist meist am reibungslosesten. |
Für deutsche Betreiber ist dabei oft ein zusätzlicher Punkt wichtig: Datenhoheit. Nicht jedes Projekt kann oder will vollständig in die Public Cloud. In solchen Fällen gewinnen hybride Modelle, private Cloud und On-Prem-Optionen an Gewicht. Das ist kein ideologisches Thema, sondern häufig eine Frage von Regulierung, Kundenerwartung und Betriebsrealität. Aus dieser Sicht sind Plattformen mit sauberem Edge-Konzept und klarer Trennung zwischen lokalem Betrieb und zentraler Analyse besonders wertvoll. Im nächsten Abschnitt zeige ich, wo Projekte in der Praxis am häufigsten scheitern.
Wo IoT-Projekte teurer werden als geplant
Die größten Kostenfehler entstehen selten bei der Lizenzfrage allein. Teuer wird es dort, wo Teams Geräte, Daten und Betrieb separat denken. Ein Pilot mit 20 Geräten sagt wenig über eine Flotte mit 2.000 Geräten aus, erst recht nicht, wenn die Hälfte der Geräte über Mobilfunk oder unsichere Standorte angebunden ist. Genau an dieser Stelle kippen viele gut gemeinte IoT-Systeme in unnötige Komplexität.
| Typischer Fehler | Was schiefläuft | Was ich stattdessen tun würde |
|---|---|---|
| Nur auf Protokolle schauen | MQTT oder HTTP sind wichtig, reichen aber allein nicht aus. | Ich prüfe immer auch Twin-Logik, Updates, Identität und Integrationen. |
| Onboarding zu spät planen | Geräte lassen sich zwar verbinden, aber nicht sauber verwalten oder ersetzen. | Ich teste Provisionierung, Zertifikate und Rücknahme schon im Pilot. |
| Edge-Fähigkeit unterschätzen | Bei Verbindungsabbrüchen gehen Daten, Aktionen oder Zustände verloren. | Ich prüfe Offline-Verhalten, lokale Pufferspeicherung und Synchronisation. |
| Kein sauberes Datenmodell | Rohdaten landen ohne Kontext im Dashboard und bleiben operativ wertlos. | Ich baue früh eine Asset-Hierarchie mit klaren Beziehungen und Statusfeldern. |
| Kein Exit-Szenario | Die Plattform wird zur Sackgasse, wenn Preise, Funktionen oder Strategie wechseln. | Ich halte APIs, Datenexport und Migrationspfad von Anfang an offen. |
| Tests nur im Idealnetz | Im Labor läuft alles, im Feld nicht. | Ich simuliere mindestens einen Ausfall, zum Beispiel 15 Minuten ohne Verbindung und einen Massen-Update-Lauf. |
Gerade bei Außenstandorten, Telekommunikationsumgebungen oder Infrastrukturprojekten ist dieser Realitätscheck entscheidend. Wenn du nur im stabilen Testnetz arbeitest, siehst du nicht, wie die Plattform mit verzögerten Nachrichten, Wiederanläufen oder teilweisen Ausfällen umgeht. Genau dort entscheidet sich, ob eine Plattform im Betrieb wirklich gut ist oder nur auf dem Papier.
Wann die Architektur wichtiger ist als der Produktname
Wenn ich eine Plattform heute für ein neues IoT-System auswählen müsste, würde ich nicht mit dem Produktnamen beginnen, sondern mit fünf Fragen: Wie viele Geräte sind es wirklich, wie oft sprechen sie, wie stabil ist die Verbindung, welche Daten dürfen wo liegen und wer betreibt das System nach dem Go-live? Erst wenn diese Fragen sauber beantwortet sind, lässt sich die Plattform vernünftig eingrenzen.
- Ich definiere zuerst das Gerätespektrum, also Sensoren, Gateways, Controller und die erwartete Lebensdauer.
- Ich entscheide dann, ob Cloud-first, Hybrid oder On-Prem im Betrieb die vernünftigste Linie ist.
- Danach teste ich Provisionierung, Device Twin oder Shadow, OTA-Updates und Rückkanalsteuerung mit echten Geräten.
- Ich prüfe die Integrationskette bis in Monitoring, Ticketing, Data Lake oder BI, nicht nur bis ins Dashboard.
- Zum Schluss simuliere ich Störungen, etwa 15 Minuten Netzunterbrechung, erneute Zertifikatsverteilung und einen Batch-Update-Lauf mit mindestens 20 bis 50 Geräten aus zwei unterschiedlichen Verbindungsarten.
Aus dieser Perspektive ergibt sich für 2026 ein recht klares Bild: AWS IoT Core und Azure IoT Hub sind die naheliegenden Kandidaten für große Cloud-Setups, Cumulocity, Siemens Insights Hub, Bosch IoT Suite und ThingWorx sind besonders stark in industriellen und infrastrukturellen Szenarien, und ThingsBoard ist die interessanteste offene Alternative, wenn du mehr Kontrolle behalten willst. Die beste Entscheidung fällt aber nicht im Prospekt, sondern im Verhalten der Plattform unter Last, bei Ausfällen und bei echten Betriebsprozessen.
Wenn ich den einen Satz behalten dürfte, dann diesen: Die beste IoT-Plattform ist die, die deine Geräte nicht nur verbindet, sondern ihren Betrieb über Jahre zuverlässig, sicher und nachvollziehbar macht. Genau daran solltest du jede Shortlist messen, bevor du dich auf einen Anbieter festlegst.
