SGP.32 in Practice: What the IoT eSIM Standard Actually Changes for Device Procurement, Profile Switching, and MNO Lock-In

June 2, 2026 · 9 min read · Technical Whitepapers

SGP.32 is the first GSMA eSIM standard built for IoT —not adapted from consumer handsets. It removes the screen requirement, introduces cloud-controlled profile switching via the eIM-IPA architecture, and eliminates SMS dependency. What changes for device procurement: the enterprise — not the MNO — controls profile switching through the eIM. At mid-2026, 50+ modules ship SGP.32-capable. If your device lifecycle exceeds 5 years, the procurement default should shift now.

TL;DR: SGP.32 is the first eSIM standard purpose-built for IoT. Unlike SGP.22 —designed for smartphones where a user taps a screen —SGP.32 assumes the device has no display, no keyboard, and possibly no human within 1,000 km. It introduces two new components: the IoT Profile Assistant (IPA) on the device, and the eSIM IoT Remote Manager (eIM) in the cloud. Together, they let the enterprise —not the MNO —trigger profile downloads, switches, and deletions across thousands of devices via API. Profile switching cost: an API call, not a truck roll. The ecosystem is at an inflection point: 50+ pre-tested modules shipping by mid-2026, SGP.32 eSIM installed base projected to grow from ~5 million to 193 million by 2028. For new deployments with 5+ year lifecycles, the procurement default should shift from SGP.22 to SGP.32 now.

Why SGP.22 Was Never Right for IoT

SGP.22 —the consumer eSIM standard —was built for smartphones. Its architecture assumes a Local Profile Assistant (LPA) driven by a user interface: the phone owner opens Settings, taps "Add eSIM," scans a QR code, and confirms the download. This works when the device has a screen and a human operator.

An NB-IoT water meter in a basement has neither. Under SGP.22, the workaround was pre-loading profiles at manufacturing (inflexible —the operator is locked in at the factory) or building proprietary OTA mechanisms tied to a single MNO's SM-DP+ server (fragile —if you change MNOs, you rebuild the mechanism). Both approaches created vendor lock-in by design: the more devices you deployed, the harder it became to switch connectivity providers.

SGP.02 —the older M2M standard —relied on SMS for profile commands. SMS is being sunset by operators globally, requires circuit-switched fallback that doesn't exist on NB-IoT or LTE-M networks, and adds per-message cost to every profile operation. It was designed in the 2G era and it shows.

SGP.32 was designed to close both gaps simultaneously: no SMS, no screen, no MNO lock-in.

The Architecture: IPA, eIM, and Who Controls the Switch

SGP.32 introduces two components that did not exist in previous eSIM standards:

The critical shift: under SGP.22, the MNO's SM-DP+ was the single point of control for profile delivery. Under SGP.32, the enterprise's eIM is the orchestrator —the SM-DP+ becomes a profile warehouse that the eIM calls when needed. If you want to switch from Vodafone to Orange across 5,000 devices in Germany, you instruct your eIM. It pushes the Orange profile to the IPA on each device. The devices load the profile over IP (CoAP + DTLS). No SMS. No truck roll. No renegotiation with Vodafone.

IPA implementation options matter for procurement:

1. IPAe (embedded in the eUICC chip): lowest integration effort. The eUICC vendor handles IPA implementation. Best for constrained devices where minimizing firmware complexity is the priority. The trade-off: you're locked to the eUICC vendor's IPA implementation and update cycle.

2. IPAd (in the device application processor): more development effort —your firmware team integrates the IPA as a software component. But you control the update cycle, security patches, and feature additions. Best for high-volume devices where firmware is already a core competency.

Source: Kigen, "IPA, LPA and SGP.32: A Practical Guide for IoT eSIM Device Integration for Product Leaders", December 2025. Available at https://kigen.com/resources/blog/ipa-lpa-and-sgp-32-iot-esim-device-integration-for-product-leaders/

How a Profile Switch Actually Works —Step by Step

The operational sequence for an SGP.32 profile switch differs fundamentally from both SGP.02 (SMS push) and SGP.22 (QR code scan):

1. The IPA on the device checks in with the eIM at a configurable interval —typically every 6-24 hours for power-optimized devices, or continuously for connected assets.

2. The eIM evaluates the device's current state: which profile is active, signal quality metrics (if reported), device location, policy rules.

3. If a profile change is warranted —better coverage available, current operator contract expiring, regulatory profile swap required —the eIM sends a profile download command to the IPA.

4. The IPA fetches the encrypted profile package from the SM-DP+ over IP (CoAP/DTLS). Profile size: typically 20-50 KB.

5. The IPA installs and enables the new profile. The old profile can be disabled (kept for fallback) or deleted.

6. The device re-attaches to the network using the new profile's IMSI.

Real-world timing from Kigen/IoT Stars testing across 5 device types (Nordic, Murata, Sequans, SG Wireless): profile download in ~1 minute, full provider switch in under 2 minutes. For a device that has been running the same profile for 3 years, this is a fundamental operational change.

No SMS means the mechanism works on NB-IoT and LTE-M networks that don't support circuit-switched fallback —which is essentially all of them. This alone makes SGP.32 viable for LPWA deployments where SGP.02 was simply non-functional.

Source: Soracom/Kigen, "The SGP.32 Reality Check: Putting the New IoT Remote SIM Provisioning Standard to the Test", 2025. Available at https://soracom.io/webinars/sgp-32-webinar/

The 2026 Ecosystem: Ready for Procurement, With Caveats

The SGP.32 ecosystem in mid-2026 is past proof-of-concept but not yet at commodity scale. Here is what procurement teams need to verify:

Module readiness: 50+ pre-tested cellular modules from Quectel, SIMCom, Telit, and others support SGP.32. But "support" means different things —some modules ship IPAe in the eUICC, others require IPAd integration. Verify IPA mode (e vs d) and whether the eUICC vendor provides production-grade IPA firmware, not just a reference implementation.

eIM provider landscape: Multiple GSMA-certified eIM providers are operational (Kigen, Soracom, Onomondo, ZARIOT, 1NCE). Each eIM is interoperable with any GSMA-certified SM-DP+ —this is a key SGP.32 design requirement. But interoperability testing is still ongoing; ask for a reference deployment matching your device profile and target MNOs.

Profile availability: Not every MNO offers SGP.32-compatible SM-DP+ access yet. The major European groups (Deutsche Telekom, Vodafone, Orange) are ahead; some regional operators in Africa and Latin America are still SGP.22-only. If your deployment includes markets where no MNO offers SGP.32 SM-DP+, you will still need multi-IMSI as a bridge.

Installed base trajectory: Kaleido Intelligence projects SGP.32 eSIM installed base growing from approximately 5 million (2025) to 193 million (2028) —a 240% CAGR. The tipping point for procurement defaults is now, not later: specifying SGP.32 in RFPs today means devices entering the field in 2027-2028 will be on the right side of the adoption curve.

Source: RCR Wireless / KORE, "How the new SGP.32 eSIM standard will transform IoT", September 2025. Available at https://www.rcrwireless.com/20250922/internet-of-things/sgp-32-esim-transform-iot

Source: Beecham Research / Wireless Logic, "SGP.32 Buyers Guide", November 2025. Available at https://iot-now.com/2025/11/26/154395-beecham-research-and-wireless-logic-demystify-sgp-32-in-new-buyers-guide/

When SGP.32 Is the Right Spec —and When Multi-IMSI Still Wins

Specify SGP.32-capable modules now when: the device lifecycle exceeds 5 years and will be deployed across multiple countries; the MNO relationship is not guaranteed for the full lifecycle (mergers, pricing changes, coverage shifts); the device has no user interface and cannot rely on manual profile management; or the deployment includes markets with evolving permanent roaming restrictions where remote profile loading is a compliance requirement, not a convenience.

Multi-IMSI is still the right answer when: the deployment starts within 6 months and SGP.32 modules are not yet available in the required volume for your specific modem/chipset combination; the target markets have no SGP.32 SM-DP+ availability and won't within 2 years; or the device firmware team does not have bandwidth to validate IPAd integration and you cannot use IPAe for your specific eUICC.

The two approaches coexist: a multi-IMSI SIM handles the immediate deployment while the next hardware revision moves to SGP.32. The architecture should plan for this transition —not treat SGP.32 as a future problem.

What SGP.32 Does Not Solve

Three things SGP.32 does not address, which procurement teams should not assume it does:

1. MNO business agreements. SGP.32 standardizes the technical interface for profile delivery. It does not create a commercial relationship between you and the MNO whose profile you want to load. You still need a contract with that MNO or a connectivity provider that aggregates MNO agreements.

2. Regulatory compliance. SGP.32 makes it technically possible to switch a device from a foreign IMSI to a local IMSI when a permanent roaming clock expires. It does not register the SIM with the local regulator, satisfy KYC requirements, or file compliance documentation. The technical capability and the regulatory obligation are separate problems.

3. Device certification. An SGP.32-capable module still needs PTCRB/GCF certification for the target network bands, CE/RED for the EU market, and any national type-approval requirements. The eSIM standard simplifies connectivity management —it does not simplify radio certification.

References

• Kigen —IPA, LPA and SGP.32: A Practical Guide for IoT eSIM Device Integration for Product Leaders (December 2025)
• Soracom / Kigen —The SGP.32 Reality Check: Putting the New IoT Remote SIM Provisioning Standard to the Test (2025)
• RCR Wireless / KORE —How the new SGP.32 eSIM standard will transform IoT (September 2025)
• Beecham Research / Wireless Logic —SGP.32 Buyers Guide (November 2025)