Blog · SGP.32 · IoT · eSIM
SGP.32 Goes Commercial: What to Test in 2026
SGP.32 IoT eSIM moved from specification to shipping SIMs in 2026. Where the standard stands, what changes for IoT teams and a practical test plan.
By SimCheck.ai team · Updated · 5 min read
In 2026, SGP.32, the GSMA’s eSIM standard for IoT, became something you can order rather than something you read about: the test specifications are published, certified eUICCs exist, and connectivity providers are shipping SGP.32 SIM cards. For IoT teams the question is no longer whether to adopt it but how to prove that devices, eIMs, profiles and networks work together before a fleet goes into the field. This post covers where the standard stands, what changes in practice, and a test plan you can start from.
Where SGP.32 stands in late 2026
The specification work took about four years from requirements to commercial SIMs:
| When | Milestone |
|---|---|
| April 2022 | SGP.31 v1.0 defines the eSIM IoT architecture and requirements |
| May 2023 | SGP.32 v1.0, the technical specification, is published |
| 2024 | SGP.32 v1.2 is released |
| January 2025 | SGP.33 test specifications v1.2 for the IoT eUICC (SGP.33-1), the IPAd (SGP.33-2) and the eIM (SGP.33-3) are published, making certification possible |
| April 2025 | Giesecke+Devrient announces the first GSMA-certified SGP.32 IoT eUICC |
| February–April 2026 | Telenor IoT opens orders for SGP.32 SIM cards in February, with deliveries from April |
Telenor IoT’s announcement is one example, but it marks the point where an enterprise can buy SGP.32 SIMs off a price list instead of joining a pilot.
Volume forecasts point the same way. Kaleido Intelligence, as reported by RCR Wireless, expects SGP.32 profile downloads to grow from around 2.89 million in 2025 to around 194 million in 2029. Treat that as a forecast rather than a measurement, but the direction is clear: the installed base is about to grow faster than most teams’ test capacity.
What changes for IoT teams
SGP.32 is not an update to the older M2M model. It is not backward compatible with SGP.02, which relied on an SM-SR to push profiles to devices. Instead it reuses the SM-DP+ infrastructure from consumer eSIM (SGP.22) and adds two IoT-specific components. Each one brings its own testing questions.
The eIM becomes a design and procurement decision
The eIM (eSIM IoT remote manager) replaces the end user of a consumer phone: it tells devices which profiles to download, enable, disable or delete. Who operates your eIM (a connectivity provider, a SIM or module vendor, or your own team) decides who can act on your fleet and how easily you can change suppliers later. Before committing, test the operations you’ll actually use at scale, not just a single download. Our explainer on what an eIM does covers the role in detail.
The IPA lives in your device or your eUICC
The IoT Profile Assistant (IPA) carries out the eIM’s instructions. It can sit in the device as the IPAd or inside the eUICC as the IPAe (compared here). With an IPAd, part of the remote provisioning stack becomes your firmware team’s responsibility, which means every firmware release is also an eSIM regression risk. With an IPAe, the logic ships with the eUICC, and the device still has to provide connectivity and handle the results.
Interoperability is the real risk
Certification against SGP.33 tests each component against the specification. It doesn’t prove that your eUICC, your IPA, your chosen eIM, the operator’s SM-DP+ and the operator’s profile work together, or that the profile attaches on the networks your devices will see. That combination is where most field failures live, and only end-to-end testing finds them.
Bootstrap profiles and fallback need as much attention as the happy path
Most SGP.32 devices leave the factory with a bootstrap profile that provides enough connectivity to reach the eIM and fetch an operational profile. The hard cases come later: an operational profile that downloads but can’t attach, an APN that doesn’t match, a partner network that rejects the IMSI. Your design needs a defined path back to a working profile, whether that’s the specification’s fallback mechanism, the bootstrap profile or device logic, and that path needs testing on a live network, not just on paper.
A practical SGP.32 test plan
The plan below works for a first device qualification and as the basis of a regression suite. How to test SGP.32 devices goes into each step in more depth.
| Stage | What to verify | Evidence to keep |
|---|---|---|
| 1. Bootstrap | Device boots on the bootstrap profile, attaches and reaches the eIM | PLMN, RAT, signal, eIM contact |
| 2. Download and enable | eIM triggers a download from the SM-DP+, profile installs and enables, ICCID changes | Timings, ICCID before and after, error codes |
| 3. Attach per market | Operational profile attaches on each target network and technology | PLMN, RAT, band, RSRP/RSRQ/SINR, reject cause |
| 4. Application path | Data session, DNS and your real protocol (for example MQTT) work on the intended APN | Round-trip results, packet captures |
| 5. Switch and recover | Switching, disabling and deleting profiles work; a failing profile leads back to a working one | Event sequence, time to recover |
| 6. Soak and regression | Attach stays stable over days; results hold after firmware, IPA or eIM changes | Uptime, attach success rate, trend reports |
A few practical notes:
- Test per network, not per country. Lock each test to a specific operator by PLMN so that a roaming partner that rejects your profile can’t hide behind one that accepts it. Record the reject cause when it happens.
- Test the technology you’ll deploy on. An LTE-M device that only ever gets tested on LTE will surprise you. Force the radio technology, and see our notes on NB-IoT vs. LTE-M testing.
- Exercise the failures on purpose. Use a profile with a wrong APN or a network you’re not permitted on, and confirm the device recovers. Real failures are rarely the ones you planned for, but a tested recovery path covers most of them.
- Keep the evidence. A decoded signaling trace and a packet capture turn a support ticket with your connectivity provider from an argument into a fix.
Where SimCheck.ai fits
SimCheck.ai runs these checks on real cellular modems with real eSIM profiles on live networks. Each modem can install profiles through SGP.32 via a cloud eIM or through an SGP.22-style LPA, and tests can force the radio technology and operator, keep decoded signaling and packet captures, and run on a schedule across the SimCheck network or your own edge devices. The SGP.32 IoT eSIM testing page shows how teams put the plan above into practice.
SGP.32 has done its job as a standard: the parts exist, they are certified and they are for sale. The work in 2026 is proving that your particular combination of them works in every market you ship to, before your devices are bolted to walls, poles and vehicles where nobody can swap a SIM.