SGP.32: Der IoT-eSIM-Standard, der die Verwaltung vernetzter Geräte verändert

Was ist SGP.32?

SGP.32 ist der GSMA-Standard für Remote SIM Provisioning, der speziell für IoT-Geräte entwickelt wurde. Er definiert die technische Architektur zur Verwaltung von eSIM-Profilen über vernetzte Geräteflotten hinweg – ohne physischen Zugriff, Nutzerinteraktion oder manuelle Konfiguration. Während frühere eSIM-Standards für Smartphones oder Legacy-M2M-Deployments ausgelegt waren, ist SGP.32 für headless IoT-Geräte gebaut: Sensoren, Zähler, Gateways, maritime Ausrüstung und autonome Fahrzeuge, die jahrelang ohne Nutzerinteraktion oder physischen Zugriff betrieben werden.

Der Standard führt zwei Komponenten ein, die es in früheren eSIM-Spezifikationen nicht gab: den eIM (eSIM IoT Remote Manager) auf der Serverseite und den IPA (IoT Profile Assistant) auf der Geräteseite. Zusammen ermöglichen sie ein Provisioning-Modell, das vollständig aus der Cloud gesteuert wird – ohne Abhängigkeit von Nutzeraktionen oder geräteseitigen Konfigurationsschritten.

Kaleido Intelligence prognostiziert für SGP.32-eSIMs bis 2028 eine CAGR von 240 %. Kommerzielle Deployments beschleunigen sich bis 2026; breitere MNO-Unterstützung und abgeschlossene Hardware-Zertifizierungen sollen das Volumenwachstum 2027 antreiben.

Warum die bisherigen Standards nicht ausreichten

Um zu verstehen, was SGP.32 verändert, hilft es zu wissen, was es ersetzt.

SGP.02 war der erste M2M-eSIM-Standard und wurde 2014 veröffentlicht. Er ermöglichte Remote SIM Provisioning für industrielle Geräte, stützte sich jedoch auf SMS als Kommunikationskanal, erforderte komplexe bilaterale Vereinbarungen zwischen Betreibern und war nicht für Flottenmanagement im großen Maßstab ausgelegt. Bei einer Geräteflotte von 10.000 Einheiten in 15 Ländern überwog die Provisioning-Komplexität von SGP.02 die Flexibilität, die es eigentlich bieten sollte.

SGP.22 löste ein anderes Problem. Es wurde für Consumer-Geräte entwickelt, vor allem Smartphones. Das Provisioning-Modell setzt voraus, dass ein Nutzer anwesend ist: jemand scannt einen QR-Code, klickt sich durch ein Gerätemenü oder installiert eine Companion-App. Für IoT-Geräte ohne Bildschirm, ohne Nutzer und ohne Interface funktioniert SGP.22 nicht wie vorgesehen. Die Branche passte sich an, statt zu warten: QR-Codes wurden in Geräteverpackungen beigelegt, Companion-Apps simulierten Nutzerinteraktionen, die das Gerät selbst nicht leisten konnte, Bootstrap-Profile erforderten Aktivierungsschritte nach dem Deployment. Nichts davon funktionierte gut über ein paar hundert Geräte hinaus.

SGP.32 beseitigt diese Anpassungen. Es ist die erste GSMA-Spezifikation, die IoT-Geräte als das behandelt, was sie sind: eingebettet, headless, oft batteriebetrieben, intermittierend verbunden und in Umgebungen eingesetzt, in denen physischer Zugriff nach der Installation nicht Teil des Betriebsmodells ist.

Wie SGP.32 funktioniert: die Architektur

SGP.32 führt eine klarere Aufgabentrennung ein als frühere Standards. Drei Komponenten übernehmen den gesamten Profil-Lifecycle.

Der eIM (eSIM IoT Remote Manager) ist die Orchestrierungsschicht. Er sitzt auf der Serverseite und trifft alle Entscheidungen darüber, welches Profil auf welches Gerät kommt, wann und unter welchen Bedingungen. In der Praxis: Der eIM stößt Profil-Downloads an, verwaltet den Profilstatus und führt Switching-Logik auf Basis vorkonfigurierter Business-Regeln aus. Alles, was in früheren Standards manuelle Aktionen oder bilaterale Betreiberkoordination erforderte, läuft jetzt von hier aus.

Der IPA (IoT Profile Assistant) ist die geräteseitige Komponente und in zwei Varianten verfügbar. IPAd läuft im Gerät selbst. IPAe ist direkt im eUICC-Chip eingebettet. Der IPA übernimmt die sichere Kommunikation mit dem eIM und führt die Profiloperationen aus, die der eIM anweist. Er ist für eingeschränkte Hardware ausgelegt: begrenzter Speicher, intermittierende Konnektivität, niedrige Energiebudgets.

Der SM-DP+ (Subscription Manager Data Preparation+) ist das Profilvorbereitungs-Backend, übernommen aus SGP.22. Er bereitet Betreiberprofile vor, speichert und liefert sie aus. In SGP.32 agiert der SM-DP+ gegenüber dem Gerät nicht mehr als steuernde Instanz. Profile werden vorgehalten, bis der eIM sie anfordert. Der SM-DP+ führt aus; der eIM entscheidet.

Die Architektur ist push-getrieben und server-orchestriert. Entscheidungen über Konnektivität werden zentral getroffen. Das Gerät erhält Anweisungen und führt sie aus. Es muss vor dem Versand nicht wissen, mit welchem Betreiber es sich verbinden wird.

Zero-Touch-Provisioning: was das in der Praxis bedeutet

Zero-Touch-Provisioning ist die operative Fähigkeit, die SGP.32 im IoT-Maßstab ermöglicht. Ein Gerät verlässt das Werk mit einem Bootstrap-Profil: einer minimalen Konnektivitätsberechtigung, die gerade genug Netzzugang bietet, um beim ersten Einschalten den eIM zu kontaktieren. Sobald der eIM erreicht ist, identifiziert er das Gerät, prüft dessen Deployment-Regeln und pusht das passende operative Carrier-Profil. Das Gerät verbindet sich im richtigen Netz, im richtigen Land, mit dem richtigen Datentarif – ohne dass es zwischen Werkhalle und Einsatzort jemand in die Hand nehmen muss.

Ein Gerätehersteller, der 50.000 Smart Meter in Europa ausliefert, beschafft SIMs nicht mehr pro Land: Eine Hardware-SKU wird überall ausgeliefert, der eIM übernimmt die lokale Aktivierung beim ersten Einschalten. Ein IoT-Reseller, der Fleet-Tracker in 30 Märkten verwaltet, sieht neue Geräte ohne Provisioning-Schritt im Feld live gehen. Auf Schiffen, die zwischen Flaggenstaaten und Hoheitsgewässern wechseln, aktualisieren sich Carrier-Profile automatisch mit der Positionsänderung. In jedem Fall verschwindet der operative Schritt, der zuvor menschliches Eingreifen erforderte.

Was SGP.32 für den Partner- und Reseller-Channel bedeutet

Die meisten veröffentlichten Inhalte zu SGP.32 richten sich an Gerätehersteller, Chip-Anbieter und Netzbetreiber. Die Partner- und Reseller-Perspektive fehlt in dieser Diskussion weitgehend – was bemerkenswert ist, weil Partner die Distributionsschicht sind, über die die meiste IoT-Konnektivität Endkunden erreicht.

Die Änderungen, die SGP.32 einführt, betreffen das Partner-Angebot direkt – und nicht nur technisch.

Globale Deployments aus einem einzigen Produkt. Vor SGP.32 bedeutete globale IoT-Konnektivität als Reseller anzubieten entweder, lokale SIMs pro Land zu beschaffen (mehrere Lieferantenbeziehungen, mehrere Rechnungen, länderspezifische Logistik) oder die Abdeckungs- und regulatorischen Einschränkungen von Permanent Roaming zu akzeptieren. SGP.32 beseitigt beides. Ein Partner kann ein SIM-Produkt anbieten, das überall funktioniert, sich automatisch im richtigen regulatorischen Kontext aktiviert und sich über seine gesamte Betriebsdauer selbst verwaltet.

Ein Managed Service, der schwerer zu kopieren ist. Ein Partner, der Zero-Touch-Provisioning, automatisiertes Carrier-Switching und Over-the-Air-Profilmanagement als Teil eines Managed-Connectivity-Pakets anbietet, liefert etwas, das Wettbewerber ohne eIM-Infrastruktur nicht erreichen können. Der operative Nutzen ist konkret: weniger Außeneinsätze, weniger Support-Eskalationen, schnelleres Onboarding und die Möglichkeit, Länder oder Carrier zu einem Live-Deployment hinzuzufügen, ohne die ausgerollte Hardware anzufassen.

Permanent-Roaming-Compliance ohne operativen Overhead. Vorschriften in Märkten wie Brasilien, Indien, der Türkei und mehreren EU-Mitgliedstaaten schränken Permanent Roaming für IoT-SIMs ein. Ohne SGP.32 bedeutet Compliance-Management in diesen Märkten separate SIM-Produkte pro Markt oder Multi-IMSI-Ansätze, die zusätzliche Komplexität erzeugen. Mit SGP.32-konformer eIM-Infrastruktur werden lokale Carrier-Profile automatisch gepusht, wenn ein Gerät in einen regulierten Markt eintritt. Compliance wird ohne manuelles Eingreifen aufrechterhalten – in jedem Markt des Deployments.

Die Rolle des eSIM Orchestrator

Die Rolle des eSIM Orchestrator unterscheidet sich sowohl vom Carrier als auch von der Connectivity-Management-Plattform, auch wenn sie mit beiden zusammenarbeitet.

Carrier besitzen das Netz. CMPs verwalten aktive Verbindungen: Nutzungsmonitoring, Alerts, Sperrung, Aktivierung. Der eSIM Orchestrator verwaltet die Profilebene darunter. Er bestimmt, welchen Betreiber ein Gerät nutzt, und aktualisiert diese Entscheidung über die Lebensdauer des Geräts – ohne physischen Zugriff und ohne dass eine bilaterale Vereinbarung zwischen dem Kunden und jedem einzelnen MNO erforderlich ist.

Diese Rolle entstand spezifisch mit SGP.32 und lässt sich nicht auf frühere Marktstrukturen abbilden. Sie ist keine logische Erweiterung der Carrier- oder CMP-Funktion. Es ist eine separate Schicht, die oberhalb des Carriers und unterhalb des operativen Dashboards sitzt und die Entscheidungen übernimmt, für die weder der Carrier noch die Standard-CMP ausgelegt waren.

TNF agiert als eSIM Orchestrator mit direkten Carrier-Beziehungen über 900+ Netze in 200+ Ländern. Das IoT-Portal ist die Schnittstelle, über die diese Orchestrierungsschicht für Partner zugänglich ist. Profil-Lifecycle-Management, Zero-Touch-Provisioning, Carrier-Switching und eIM-Operationen sind über dieselbe Plattform verfügbar wie SIM-Lifecycle-Management, Abrechnung und Reporting.

SGP.32 und das Permanent-Roaming-Problem

Permanent-Roaming-Regulierungen zählen zu den stärksten kommerziellen Treibern für die SGP.32-Adoption. Wenn ein Gerät seine Betriebsdauer in einem fremden Netz verbringt, verlangen manche Regulierer, dass es irgendwann in ein lokales Netz wechselt. Die Definition von „irgendwann“ variiert je nach Markt, aber das regulatorische Risiko ist real und hat zu Konnektivitätsausfällen bei Betreibern geführt, die nicht dafür geplant hatten.

Ohne SGP.32 bedeutet das, Geräte pro Markt mit lokalen SIMs vorzu-provisionieren, was Hardware-Komplexität und Supply-Chain-Overhead erzeugt, oder Multi-IMSI-Lösungen zu betreiben, die funktionieren, aber nicht standardisiert sind und laufendes Management erfordern.

Der eIM überwacht den Deployment-Kontext und pusht ein lokales Carrier-Profil, wenn regulatorische Schwellenwerte erreicht werden. Der Wechsel erfolgt ohne Außeneinsatz. Für Partner, die in regulierte Märkte verkaufen, wird aus einem Deployment-Blocker eine gemanagte Fähigkeit, die sie in ein Standard-Connectivity-Paket aufnehmen können.

SGP.32-Adoption: wo der Markt steht

Die Spezifikation erreichte 2023 Reife. Die Hardware-Zertifizierung für eUICC-Chips mit IPAe-Unterstützung schritt 2024 und 2025 voran. Auf dem Mobile World Congress 2026 wurde SGP.32-Readiness von mehreren Betreibern als entscheidendes Kriterium in der Enterprise- und Automotive-IoT-Beschaffung beschrieben. Soracom eröffnete im März 2026 Vorbestellungen für seinen SGP.32-kompatiblen Connectivity Hypervisor und nannte Live-Feldtests im Automotive-Bereich als Grundlage.

Das Ökosystem reift auf der MNO-Seite noch. Nicht jeder Betreiber hat SGP.32-Support in seinem Netz abgeschlossen, wodurch der Pool an über eIM verwaltbaren Carrier-Profilen noch wächst. Partner, die SGP.32-basierte Produkte evaluieren, sollten vor Produktzusagen die Carrier-Abdeckung in ihren konkreten Deployment-Märkten prüfen. Ein Anbieter, der bereit ist, eine aktuelle Liste zertifizierter Carrier-Profile und unterstützter Märkte zu teilen, ist leichter zu vertrauen als einer, der nur über die Roadmap spricht.

Worauf Sie bei einem SGP.32-ready Connectivity-Provider achten sollten

Eine Reihe von Anbietern verweist in ihrer Positionierung auf SGP.32, ohne die vollständige Architektur implementiert zu haben. Bevor Sie ein Deployment zusagen, lohnt es sich, einige Punkte direkt zu verifizieren.

Ob der Anbieter einen eigenen eIM betreibt oder den Zugang zu einem Drittanbieter weiterverkauft, ist entscheidend für SLA-Kontrolle, Provisioning-Zeiten und die Tiefe der Carrier-Beziehungen hinter der Plattform. Ein weiterverkaufter eIM bedeutet eine Abhängigkeit von der Verfügbarkeit und den kommerziellen Vereinbarungen einer anderen Partei.

Die Integration zwischen eIM und Connectivity-Management-Plattform ist der Unterschied zwischen einer operativen Oberfläche und zwei Systemen, die synchron bleiben müssen. Wenn Profil-Lifecycle-Management und Nutzungsmonitoring in getrennten Tools liegen, materialisiert sich die operative Effizienz, die SGP.32 liefern soll, nicht vollständig.

Auf der Hardware-Seite bestimmt die Unterstützung von IPAd- und IPAe-Implementierungen, welche Gerätedesigns mit der Infrastruktur kompatibel sind. Anbieter, die nur eine Variante unterstützen, begrenzen die Hardware-Optionen für ihre Partner und Kunden.

Schließlich ist zertifizierte Carrier-Abdeckung in konkreten Deployment-Märkten nützlicher als eine headline Network Count. Die Gesamtzahl der Netze, auf die ein Anbieter zugreift, sagt weniger über SGP.32-Readiness aus als zu wissen, welche dieser Netze die eIM-Zertifizierung für die Märkte abgeschlossen haben, in denen Ihre Geräte tatsächlich betrieben werden.

Drei Deployments, die den Unterschied veranschaulichen

Smart Metering, Energiesektor. Acht Tausend Monitoring-Sensoren müssen über Standorte in Deutschland, Polen, Rumänien und der Türkei live gehen. Alle vier Länder haben unterschiedliche Carrier, und in der Türkei gibt es Permanent-Roaming-Beschränkungen. Der Hersteller liefert eine Hardware-SKU mit einem Bootstrap-Profil aus. Jeder Sensor schaltet sich ein, kontaktiert den eIM und erhält das korrekte lokale Carrier-Profil. Die regulatorische Anforderung der Türkei wird ohne separates SIM-Produkt oder einen Konfigurationsschritt im Feld erfüllt. Das Operations-Team verwaltet die gesamte Flotte ab Tag eins über eine Plattform.

Vessel Tracking, nordeuropäische Logistik. Zweihundert Schiffe, die zwischen Häfen in Norwegen, Dänemark, Deutschland und den Niederlanden verkehren, benötigen zuverlässige Konnektivität, während sie zwischen Hoheitsgewässern wechseln. Jede Änderung des Carrier-Profils erforderte früher Koordination zwischen dem Schiffsbetreiber und dem Connectivity-Provider. Jetzt verfolgt der eIM die Schiffsposition und aktualisiert Carrier-Profile, wenn Schiffe Abdeckungszonen überschreiten. Das Operations-Team verwaltet keine einzelnen SIM-Änderungen. Was früher Support-Tickets erzeugte, wurde zur Hintergrundinfrastruktur.

Fleet Telematics, globaler Betreiber. Ein MSP verwaltet Telematikgeräte für 15.000 Fahrzeuge in Europa, dem Nahen Osten und Südostasien. Neue Fahrzeuge kommen mit bereits eingebetteten Geräten an. Der eIM aktiviert die Konnektivität beim ersten Zündvorgang. Wenn Fahrzeuge anderen Regionen zugewiesen werden, aktualisieren sich Carrier-Profile ohne SIM-Austausch oder Außeneinsätze. Die Kunden des MSP sehen ein Dashboard. Der MSP erhält eine Wholesale-Rechnung. Der Logistik-Overhead, der früher mit der Flottengröße skalierte, skaliert nicht mehr.

Zusammenfassung

SGP.32 verlagert Provisioning-Entscheidungen vom Gerät auf den Server, beseitigt die Abhängigkeit von physischem Zugriff für Profiländerungen und macht eine Hardware-SKU in jedem Deployment-Markt nutzbar. Permanent-Roaming-Compliance verschiebt sich von einem pro-Markt-Logistikproblem zu einer gemanagten eIM-Funktion. Die Rolle des eSIM Orchestrator, die vor SGP.32 nicht als definierte kommerzielle Funktion existierte, wird zur Schicht, die übernimmt, wofür weder Carrier noch CMP ausgelegt waren.

Für Partner und Reseller erweitert der Standard, was ein Managed-Connectivity-Angebot enthalten kann. Zero-Touch-Aktivierung, automatisiertes Carrier-Switching und Over-the-Air-Profilmanagement sind über Retail-SIMs, Single-Carrier-Verträge oder Standard-CMP-Plattformen ohne dahinterliegende eIM-Infrastruktur nicht verfügbar. SGP.32 ist die Spezifikation, die diese Fähigkeiten standardisiert, zertifizierbar und im großen Maßstab lieferbar macht.