SGP.32: the eSIM standard built for IoT, explained for Africa

Remote SIM provisioning for devices with no screen, no human, and a fence-line 800 km from the nearest engineer. What SGP.32 changes for African fleets, what it does not replace, and the five questions to ask any connectivity partner before you commit.

The short version

SGP.32 is the new GSMA standard that finally makes remote eSIM provisioning practical for IoT: loading, switching, enabling and disabling operator profiles on an embedded SIM (eUICC) over the air, securely, at fleet scale, without anyone touching the device.

It is a genuine shift in how IoT connectivity gets delivered over the next 18–36 months. But it is not a replacement for real-time multi-IMSI network steering, it does not remove African regulatory complexity, and it does not change how a device behaves on the network. The standard is the easy part. The local partner is the hard part.

What is SGP.32?

SGP.32 is the GSMA technical specification for eSIM IoT remote SIM provisioning (RSP). It lets a network-side manager load, enable, disable and switch mobile operator profiles on an embedded SIM (eUICC) remotely and securely, with no user interface, no QR code, and no human present at the device.

It reuses the modern consumer-eSIM back end (the SGP.22 SM-DP+) but replaces the human-driven on-device app with a cloud-side fleet manager (the eIM) and a lightweight on-device agent (the IPA). It is not a merge of the old M2M and consumer protocols; it is the consumer architecture re-pointed at unattended IoT fleets.

Specification	SGP.02 (M2M, 2013)	SGP.22 (consumer, 2016)	SGP.32 (IoT, 2023/24)
Built for	Headless M2M modules	Phones, tablets, wearables	Unattended IoT fleets
Who triggers a profile change	Operator, via SM-SR	A person, on the device	The eIM, network-side
On-device agent	None	LPA (needs a screen)	IPA (IPAd or IPAe)
Back end	SM-SR + SM-DP	SM-DP+	SM-DP+ (reused from SGP.22)
Transport	SMS	HTTPS	HTTPS or CoAP, no SMS dependency
Fallback profile	No	No	Yes, enforced by the eUICC

The three new pieces: eIM, IPA and the reused SM-DP+

SGP.32 introduces three logical entities on top of the existing consumer-eSIM RSP infrastructure. The cryptographic chain (ECDSA signatures, the EUM/CI certificate hierarchy, the Bound Profile Package) is unchanged, which is why vendor enablement is moving fast.

The IPA comes in two forms: IPAd, which lives in the device firmware, or IPAe, baked into the eUICC itself so the device maker does less work. Either way it is an interface, not a black box: a connectivity partner can build a local profile-management layer on top of the IPA, adding policy, profile cataloguing and market-specific profile selection between the eIM and the eUICC. That interface is exactly where an Africa-first operator adds value the raw standard does not.

The four features that actually matter for African conditions

Most market commentary under-represents these, and they are exactly the parts that matter when a device is in a borehole, on a fence line, or hundreds of kilometres from a field engineer: the fallback profile (eUICC-enforced switch to a designated profile if the active one fails), the provisioning / emergency profile (bootstrap connectivity that survives field changes), the default SM-DP+ (the IPA can self-initiate a download without an eIM in the loop, useful for greenfield activation), and signed eUICC packages (every profile state change independently signed and verified at the eUICC, not just at the network edge).

What SGP.32 changes, and what it doesn't

What it changes

• Logistics collapse. Stop shipping physical SIMs across borders to commission devices in Lagos, Nairobi, Lusaka or Kinshasa. Manufacture anywhere, ship anywhere, provision the right profile after the device lands. For cross-border dashcam, PTT and container-tracking fleets, this is the single largest operational benefit.
• Permanent-roaming compliance gets cheaper. Provision a locally-compliant operator profile remotely instead of rotating SIMs or accepting roaming risk, provided your partner holds the local relationship in that market.
• Lifecycle becomes a software problem. Above a few thousand SIMs, profile catalogues, signed state changes, audit trails and fleet-wide policy turn SIM management from logistics into managed software: the point at which it pays to manage the profile lifecycle from one platform.

What it does not change

• It does not replace multi-IMSI. SGP.32 handles deliberate, signed, multi-second profile operations, not sub-second network steering.
• It does not remove African regulatory complexity. SIM registration (NCC), ICASA requirements, type approval and data localisation all still apply. More local profiles means more local relationships, not fewer.
• It does not eliminate cost: it shifts it. It cuts truck rolls and returns, but adds per-profile RSP fees (typically ~$0.50–$2.00/download) and eIM platform fees. On a stable single-profile fleet, unit cost can go either way. Model it per deployment.
• It does not change the device. APN handling, modem firmware, attach order, NB-IoT vs LTE-M, GPS (where most field faults actually originate) are untouched.

SGP.32 vs multi-IMSI: two different layers

They are complementary layers: a serious deployment typically needs both.

• SGP.32: profile lifecycle (deliberate · signed · multi-second): decides which operator profile is loaded onto the eUICC and manages its lifecycle over the air. Think onboarding a device to a new market, or swapping to a locally-registered profile for compliance.
• Multi-IMSI: network steering (real-time · autonomous · sub-second): decides which network the device uses right now: when you cross from South Africa into Botswana, or MTN coverage drops to a Vodacom-only area. This is multi-IMSI logic on a single profile, the way the Cloud Connect SIM already works.

SGP.32 is the protocol. Africa is the moat. A partner who treats SGP.32 as a substitute for multi-IMSI is hiding a gap.

The 5 questions to ask your connectivity partner

The same five questions apply whether you're talking to us or to anyone else. They separate SGP.32 readiness from SGP.32 theatre.

1. Whose eIM signs the profiles on our devices, and what's the per-profile commercial model? The eIM controls your fleet's SIM lifecycle. Know whose hands are on it, and what each profile download costs over the life of the device.
2. In which African markets do you have a local profile relationship today, and which are still on a roaming profile? The standard means nothing if there's no local profile in the market you're deploying into.
3. Show me the relationship between your SGP.32 capability and your real-time multi-IMSI capability. Different layers. A partner who can articulate both is doing IoT properly; a partner who conflates them is hiding a gap.
4. What's your fallback design if the eIM is unreachable when a profile change is needed? SGP.32 supports a fallback profile and an emergency profile. If your devices are somewhere you can't physically reach, this matters more than it sounds.
5. What's your SGP.32 roadmap for this specific deployment, with dates? “We're SGP.32-ready” is a positioning claim. “We will provision your fleet under SGP.32 from Q3 2026 in markets X, Y, Z” is a commitment. Insist on the second.

Where CommsCloud sits on this

SGP.32 is a real shift in how the industry will deliver IoT connectivity over the next 18–36 months, and we are deliberate about how we adopt it. We are working with our RSP partner on bringing SGP.32 capability into our Cloud Connect SIM model in 2026, with local profile partners across South Africa, Nigeria and Kenya, and production deployments targeted for Q4 2026 / early 2027.

Our view on the underlying value is unchanged: Africa-first connectivity needs cross-border resilience, local profile relationships in the markets you actually deploy into, device-level engineering that prevents field faults, and real humans who pick up the phone. SGP.32 is a powerful new way to deliver that. It is not a substitute for any part of it.