Will SGP.32 change how you deploy IoT? Here's what it really means.

As IoT fleets edge past the million-device mark, traditional Remote SIM Provisioning starts to look like a heavyweight relic—slow, chatty, and impossible to scale without carrier lock-in gymnastics. Enter GSMA SGP.32, the first eSIM standard engineered specifically for constrained, battery-powered devices. By swapping SMS and HTTPS for CoAP/UDP, introducing the cloud-native eIM manager, and enabling true zero-touch bootstrap, SGP.32 promises to rip weeks, and truck-rolls, out of your deployment timeline. In this post, we unpack what the spec actually changes, where it still needs polish, and how forward-thinking CTOs can turn it into a competitive advantage today.

27.06.2025

eSIM
SPG.32

Why SGP.32 is suddenly on every CTO’s 2025 road-map

GSMA released the stable SGP.32 v1.2 technical specification on 27 June 2024. It is the first Remote SIM Provisioning (RSP) model built expressly for resource-constrained IoT devices. Early operator pilots are scheduled for late 2025, while silicon vendors already have sample eUICCs in certification.

For CTOs managing global fleets, SGP.32 promises to:

Eliminate SMS and heavy HTTPS from the provisioning path

Cut signalling overhead by switching to CoAP/UDP with DTLS 1.3

End single-operator lock-in without complex multi-IMSI work-arounds

Simplify permanent-roaming compliance via local profile download

What is SGP.32?

A timeline of eSIM standards

Before diving into what SGP.32 delivers, it helps to see the road that led here. The eSIM playbook has evolved through four major standards, each aimed at a different device class and pain-point. The timeline below shows how remote SIM Provisioning moved from SMS-heavy, operator-centric roots to the lightweight, IoT-first architecture we have today.

2016 – SGP.02 (M2M): first machine-to-machine RSP; SMS-heavy, operator-centric.

2019 – SGP.22 (Consumer): SM-DP+ model; HTTPS profile download; user interaction required.

2023 – SGP.31 (IoT requirements): defines actors and flows for constrained devices.

2024 – SGP.32 (IoT technical): lightweight CoAP/UDP, eIM manager, SM-DS v2.

Inside the SGP.32 architecture

SGP.32 introduces four key building blocks:

eIM (eSIM IoT Manager) – cloud component orchestrating profile lifecycle.

IPA (IoT Profile Assistant) – thin client on the device or eUICC handling CoAP.

IAS (IoT Asset) – logical pairing of device and SIM.

SM-DS v2 – updated discovery service for push notifications.

All traffic can flow over CoAP/UDP secured by DTLS 1.3, removing the need for SMS fall-back and allowing devices to stay in deep-sleep between short bursts (source: gsma.com zipitwireless.com).

Five practical improvements over legacy RSP

True zero-touch bootstrap – ship devices with blank eUICCs; first operational profile pulls itself on power-up.
Significantly lower signalling overhead – binary CoAP packets replace long-lived HTTPS sessions, ideal for NB-IoT/LTE-M.
No vendor lock-in – multi-profile design plus standard eIM APIs make operator switching a back-end task.
Native power-saving – RSP commands align with PSM/eDRX cycles, so no keep-alive pings drain batteries.
Local-profile enablement – stay legal in markets that ban permanent roaming by downloading an in-country profile remotely.

What changes in your deployment workflow?

Factory stage

Before: load bootstrap profile, test IMSI, seal device.
With SGP.32: ship blank eUICC; a QR-code (or API call) links the device to the eIM.

In-field profile swap

Before: SMS trigger → HTTPS download (minutes).
With SGP.32: CoAP push completes in seconds while the device stays mostly asleep.

Fleet operations

Before: multiple SIM SKUs per region and carrier.
With SGP.32: one global SIM SKU plus remote profile catalogue.

Result: fewer truck rolls, simplified logistics and faster regulatory sign-off.

Security & compliance

SGP.32 mandates mutual authentication between eIM and eUICC and signs every profile package end-to-end. When paired with IXT SecureNet’s private APN/VPN layer (static IPs, IPSec tunnels, cloud-direct gateways) you get true defence-in-depth.

Key controls include:

TLS 1.3/DTLS 1.3 with forward secrecy for all RSP traffic

Hardware-backed root-of-trust in the eUICC

Optional SASE overlay via SecureNet for zero-trust segmentation

Readiness checklist for CTOs

Before you start phasing SGP.32 into live projects, run through this readiness checklist. It distils the core hardware, firmware, and back-end requirements we see most teams underestimate, plus a few metrics worth tracking during pilots. Treat it as a pre-flight inspection: confirm each item now and you’ll avoid the certification delays, battery surprises, and profile-swap failures that can derail an otherwise solid rollout.

Hardware: third-generation eUICCs advertised as “SGP.32-ready” (e.g., IDEMIA IST, Thales Gemalto).

Firmware: CoAP/LwM2M stack; capability to wake for push notifications.

Back-end: update connectivity-management platform to handle eIM and SM-DS v2 callbacks.

Connectivity partner: verify multi-operator profile catalogue and local-profile rights in key markets.

Pilot KPIs: swap success rate, average provisioning time, battery delta after profile change.

Where SGP.32 fits into the IXT portfolio

One global eSIM: already provides pooled data across regions. SGP.32 adds the option to pull a compliant local profile where permanent roaming is restricted.

SecureNet: tunnels both application traffic and RSP signalling through private networks, satisfying GDPR and enterprise compliance

Global Data Pool: profile swaps never break your cost control, because all SIMs still draw from one global pool

Explore global connectivity with IXT's SIM.

SGP.32 deployment takeaways and next steps for CTOs

SGP.32 doesn’t just tweak Remote SIM Provisioning, it rewrites it for IoT reality. By swapping heavyweight HTTPS for CoAP, introducing the eIM manager and enabling true zero-touch profile swaps, it removes the classic CTO headaches of power budget, lock-in and compliance.