Insights

GSMA SGP.02 M2M eSIM: what it changes for IoT SIM buying

October 12, 2026 · 9 min read · Technical Whitepapers

GSMA SGP.02 M2M eSIM: how the SM-SR dependency shapes IoT SIM, eSIM and CMP buying decisions and migration timing for fleet rollouts.

GSMA SGP.02 is the M2M eSIM specification that first made remote profile provisioning practical for IoT SIM hardware. It arrived in 2014, SGP.22 followed in 2016, and SGP.32, the IoT-focused rewrite, was finalised in May 2023. For anyone specifying SIMs, eSIMs or a CMP platform today, that chronology is the buying question.

What GSMA SGP.02 M2M eSIM means for IoT SIM procurement

Velocity IoT places SGP.02 as the GSMA specification that defines remote SIM provisioning for machine-to-machine environments, alongside SGP.22 for consumer devices and SGP.32 for IoT. Telenor IoT describes how early M2M eSIM provisioning worked: server-driven, and often using SMS for communication. The commercially decisive part is that profile management runs through the SM-SR.

That single role is why SGP.02 procurement looks different from buying a physical IoT SIM. Wherever SIM characterises SGP.02 as dependent on complex integrations with clear vendor lock-in through the SM-SR, and the SGP.32 guide at sgp32.co.uk states that the SM-SR locked enterprises to single operators. The entity holding that role sits between you and any operator change for the life of the device, which turns an operator switch into a programme rather than a purchase order.

The newer standard attacks exactly that. SGP.32 replaces the SM-SR with the eIM, separating profile preparation from delivery management and creating multi-operator flexibility for the device lifetime (sgp32.co.uk). If an eUICC is specified today and expected to run for years, which provisioning generation it implements is a hardware decision with contractual consequences.

Where an SGP.02 eSIM bill accumulates

Hardware. An eUICC is soldered, not slotted. SIMPM's standards guide assigns that layer to ETSI, covering the MFF2 chip form factor, how the chip is soldered and traditional UICC standards, while 3GPP owns radio protocols such as 5G NR, LTE-M and NB-IoT, and GSMA owns the profile software. Because the part is soldered, there is no field SIM swap: a wrong profile is remediated at board level or not at all, which shifts spend out of the SIM line and into installation and maintenance.

Connectivity. GlobalIoT.sim publishes catalog prices per country as a data rate in EUR per GB plus a monthly fee per active SIM, FOB and in EUR. Rates are published for 166 countries; other covered countries are priced on request. The lowest published figures across all priced countries are data from €1.0282/GB (roughly €1.03/GB) and a SIM fee from €0.1428 per active SIM per month. Those are global floors, never the price of a named country.

Put those floors through a worked example. 5,000 active SIMs at €0.1428 per SIM per month come to €714 per month in SIM fees, or €8,568 over 12 months. If those devices average 500 MB each per month, the fleet moves 2,500 GB per month; at €1.0282/GB that is €2,570.50. Change the country mix and both numbers move, because each country carries its own published rate.

Platform, installation and maintenance. Under SGP.02 the profile-management layer is coupled to the connectivity contract through the SM-SR, so platform selection and operator selection are not independent decisions. On the GlobalIoT.sim side the control layer is the CMP platform, with a RESTful API for activation, suspension and usage reporting. eSIM over-the-air profile provisioning is quoted separately and carries no published rate, so it belongs in the platform budget line rather than the data line.

Trigger conditions for SGP.02, SGP.22 or SGP.32

Pick on device characteristics, not on a standard's age. If the hardware has a user interface and a person completes activation, SGP.22 applies, which Telenor IoT describes as the variant introduced for devices with a user interface. If the device has no user interface, runs on constrained power or sits behind limited connectivity, and the fleet needs automated connectivity management, SGP.32 is the designed match, per Velocity IoT.

If the programme is a single-operator, very high-volume automotive-style build with the operator fixed for the device's life, SGP.02's design centre is not disqualifying: Wherever SIM notes the standard was geared to huge projects with millions of SIM cards, provided the SM-SR dependency is priced into the contract. Where an SGP.02 estate already exists in the field, the live question is migration sequencing and term alignment, not an immediate standard swap.

Deployment contexts where an SGP.02 eUICC still ships

Soldered telematics and automotive-scale programmes are the reference case: Wherever SIM notes the standard was built around fleets with millions of SIM cards. The buying path there is a Global IoT SIM covering 180+ countries with 2G/3G/4G/5G, LTE-M and NB-IoT where available, plus eSIM over-the-air provisioning for profile changes after units are sealed.

Low-power sensors and meters are the second context. The SGP.32 guide at sgp32.co.uk notes that NB-IoT devices often run to kilobyte daily data budgets, which is why SGP.32 profile operations use CoAP over UDP with DTLS instead of HTTPS-class traffic. On those fleets, day-to-day operations live in the CMP platform and its RESTful API rather than in a SIM management spreadsheet.

Multi-country rollouts are the third. A fleet attaching in dozens of countries wants one published schedule and one management plane: per-country rates across 166 countries with the rest on request, one CMP platform, one API. Where the eUICC is soldered and cannot be replaced in the field, profile portability is settled before board release.

A standards-layer checklist before you sign an SGP.02 contract

SIMPM splits the stack three ways: ETSI handles the building materials, including the MFF2 chip form factor, how the chip is soldered and traditional UICC standards; 3GPP handles the connection pipelines, including 5G NR, LTE-M and NB-IoT; GSMA handles the software layer where SGP.02 and SGP.32 sit. Require every module, eUICC and SIM claim from a supplier to name the body and the requirement it maps to.

Two checks are specific to this topic. First, establish the eUICC generation: sgp32.co.uk reports SGP.32 v1.2 as the current specification with certified modules reaching the market, which means module road maps are still in motion. Second, establish who performs the profile-management role for the contract term and what happens at exit, because that role is what creates the single-operator lock under SGP.02. The sources used here set out the standards layer only; they do not cover region-specific telecom regulation.

SGP.02 parameters a SIM buyer should verify in writing

Pitfalls and the tests that catch them before scale

Lock-in hides in contracts. Wherever SIM describes SGP.02 profile management as locking enterprises to single operators through the SM-SR. Test that before signature: ask which legal entity performs the role, whether profile portability survives the end of the term, and whether an operator change requires replacing hardware.

Provisioning transport behaves differently on constrained radios. Telenor IoT notes that early M2M provisioning was server-driven and often used SMS. Test profile download on the exact radio and power mode you will ship, LTE-M or NB-IoT with the device in its normal duty cycle, rather than on a lab bench with a strong signal.

Profile-operation data overhead is easy to miss. Compare the footprint of CoAP-with-DTLS profile operations against HTTPS-class provisioning on a device whose daily budget is kilobytes (sgp32.co.uk). Then test irreversibility: a soldered MFF2 eUICC cannot be swapped in the field, so provisioning work belongs on bench units before the board release. GlobalIoT.sim charges physical test SIMs at the normal card price and provides an eSIM test profile at no cost.

Module timing is the last trap. SGP.32 v1.2 is the current specification and certified modules are still reaching the market (sgp32.co.uk), so a migration plan that assumes today's catalogue is already complete is untested.

What the May 2023 specification change did to eSIM buying

Transforma Insights dates the split: SGP.02 and SGP.22 arrived in 2014 and 2016, and the SGP.32 specification was finalised by the GSMA Working Group 7 in May 2023. The change is architectural. SGP.32 replaces the SM-SR with the eIM, separating profile preparation from delivery management and creating multi-operator flexibility for the device lifetime (sgp32.co.uk).

For buyers, that moves operator choice from a device-lifetime commitment to a contract-term decision, where the module supports it. It also splits the eSIM provisioning line from the data line, since provisioning is quoted separately while data and SIM fees sit on a published per-country schedule. And it changes the job of a CMP platform: with the SM-SR out of the path, platform value sits in fleet operations and API automation rather than in being the only route to a profile.

How to buy: when a published per-country rate is enough

Published per-country rates are sufficient when the fleet is small or concentrated, the data profile is fixed, and no profile churn is expected. Take the per-country data rate and the SIM fee, multiply by the fleet, and compare against the budget. If that figure works and the eUICC generation is settled, the transaction is straightforward.

A project quote is the better route when volumes are large, the rollout spans many countries, or eSIM over-the-air provisioning is required, since that is quoted separately. GlobalIoT.sim routes larger volumes and multi-country rollouts that way, with coverage in 180+ countries and 2G/3G/4G/5G, LTE-M and NB-IoT where available. Validation is cheap to arrange: an eSIM test profile is free, while physical test SIMs are charged at the normal card price.

SGP.02 and SGP.32 facts that change an IoT SIM purchase

SGP.02 versus SGP.32 for M2M and IoT fleets

Frequently Asked Questions

When should an IoT integrator use SGP.32 instead of SGP.02?

When the device matches what SGP.32 was designed for: limited connectivity, low-power operation or no user interface, plus automated connectivity management at fleet scale (Velocity IoT). SGP.32 also replaces the SM-SR with the eIM, which removes the single-operator lock that Wherever SIM attributes to SGP.02. Where eUICCs already carry SGP.02 profiles in the field, the practical answer is migration sequencing within contract terms rather than an immediate swap.

What is the eIM in SGP.32?

The eIM is the role that replaces the SM-SR in SGP.32. The SGP.32 guide at sgp32.co.uk states that it separates profile preparation from delivery management, which is what creates multi-operator flexibility for the device lifetime. For procurement, it decouples the entity that prepares profiles from the entity that delivers and manages them, so operator switching stops being a device-lifetime lock.

What is the difference between SGP.22 and SGP.32?

SGP.22 was introduced in 2016 for consumer devices with a user interface, where a person manages the profile (Telenor IoT, Transforma Insights). SGP.32 is the IoT variant: it targets devices with limited connectivity, low power or no user interface, and uses CoAP over UDP with DTLS for profile operations instead of HTTPS-class traffic, which matters for devices with kilobyte daily data budgets (sgp32.co.uk).

What are the newest eSIM standards for IoT?

Across the sources used here, the newest Remote SIM Provisioning variant for IoT is SGP.32, finalised by the GSMA Working Group 7 in May 2023 (Transforma Insights). The SGP.32 guide at sgp32.co.uk reports v1.2 as the current specification with certified modules reaching the market, so module availability is still a moving part. The live question is therefore when your chosen module supports it, not whether the standard exists.

What is the GSMA Discovery Service and why does it matter?

The sources reviewed for this analysis do not describe a GSMA Discovery Service, so any detail here would be unreliable. What they do establish is that SGP.02 profile management runs through the SM-SR, and that this dependency is what locked enterprises to single operators (Wherever SIM, sgp32.co.uk). That is the question to put to a supplier: which entity performs profile management, and what happens at the end of the contract?