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

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).

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. 

About the author

IXT writes about IoT connectivity because we build it. We’re a Full-MVNO with our own core network and a CMP we designed in-house, so we see what works at scale and what doesn’t. Our team has decades of experience in M2M/IoT, from network engineering to enterprise rollouts, so the guidance we share is practical, vendor-agnostic and field-tested. Connect, secure and manage devices with confidence using our IoT Connectivity.

IXT – Connected. Secure. Everywhere.