SGP.32 vs SGP.22 and Why It Matters for IoT SIM Connectivity

If you are buying an eSIM-enabled smartphone, SGP.22 is probably exactly what you need. If you are deploying 10,000 electricity meters, environmental sensors, vehicle trackers, payment terminals or industrial routers, it may be the wrong architecture entirely. That is the heart of SGP.32 vs SGP.22, and it is why the difference between two GSMA document numbers now matters to anyone buying cellular IoT connectivity.

SGP.32 vs SGP.22 at a glance

Both are GSMA specifications for remote SIM provisioning. Both let mobile operator profiles be downloaded to an eUICC instead of permanently tying a device to the credentials loaded at manufacture. Both can correctly be called eSIM. But they were designed to solve different problems, and that changes who starts a profile download, how a fleet is managed, and how much freedom you keep over your connectivity for the life of the hardware.

None of this makes SGP.22 obsolete or inferior. It solved the consumer eSIM problem remarkably well, which is why changing provider on a modern phone no longer means hunting for a paperclip. The trouble starts when a consumer architecture is assumed to solve the IoT problem automatically. It does not.

First, “eSIM” does not mean one thing

The word eSIM has become dangerously broad. A manufacturer can advertise an industrial router as “eSIM capable” and be entirely correct, while that router behaves very differently from another product carrying the same badge. Several separate things are being bundled into one word:

• the physical form of the SIM, whether a removable card, a soldered MFF2 chip or an integrated iSIM;
• the secure element, the eUICC, that can store and manage downloadable profiles;
• the remote provisioning architecture used to put profiles onto it (SGP.02, SGP.22 or SGP.32);
• the management platform that controls the whole process.

These are related, but they are not interchangeable. An eUICC can be soldered to a circuit board, built into other silicon, or packaged inside something that looks exactly like an ordinary plastic SIM. For the SGP.32 vs SGP.22 question, whether the SIM can be removed is almost irrelevant. What matters is how operator profiles are provisioned and managed. If the hardware vocabulary is still fuzzy, our guide to consumer, business and IoT SIMs untangles SIM, eSIM, eUICC and iSIM before going further.

From SGP.02 to SGP.22 to SGP.32

SGP.32 makes more sense as the third major attempt to solve remote SIM provisioning than as something that appeared from nowhere.

SGP.02: the original M2M approach

The GSMA’s first remote provisioning architecture was built for machine-to-machine use. Long before consumers wanted eSIM in a phone, car makers could see the problem with loading connectivity credentials at the factory and hoping they suited the product for life. A vehicle built in Germany might end up in Britain, France, Australia or Brazil, and hard-wiring its connectivity future on the production line is limiting.

SGP.02 let operators manage subscriptions remotely, but it was operator-led and heavy to integrate, relying on a tightly coupled SM-SR platform and, often, SMS to trigger operations. It suited very large programmes such as automotive. It was much less attractive as a universal answer for the huge variety of devices that became known as IoT.

SGP.22: consumer eSIM arrives

The consumer architecture took the opposite approach and built around devices like smartphones. Its key device-side component is the Local Profile Assistant, or LPA, which manages profiles and talks to the provisioning infrastructure. In everyday use the journey looks like this:

The customer buys a plan, receives an activation code, the phone’s LPA uses it to contact the operator’s SM-DP+, the profile downloads securely to the eUICC, and the user enables it. For a smartphone this is an excellent system. There is a display, a user, plenty of processing power and reliable IP connectivity. The device can present choices and ask for consent.

Why SGP.22 becomes awkward for IoT

Now remove every one of those assumptions. Picture a water meter installed beneath a pavement. It wakes briefly, sends a few bytes and goes back to sleep. There is no touchscreen and no camera to scan a QR code. There may not even be an application processor capable of running a consumer-style LPA. Nobody is supposed to touch it for a decade.

Or think of a battery-powered environmental sensor on NB-IoT, an asset tracker crossing borders, an industrial gateway in an unmanned roadside cabinet, or ten thousand identical devices shipped to twenty countries before the manufacturer knows which network will serve them. These are fundamentally different environments from a phone in someone’s pocket.

Consumer eSIM can be adapted to some IoT applications, and manufacturers have done exactly that. Industrial routers with capable Linux-based processors can run SGP.22-style implementations well. But adapting something to a job is not the same as designing it for that job. So the GSMA wrote an architecture specifically for IoT: SGP.31 sets out the architecture and requirements, and SGP.32 is the technical specification that implements them.

What is SGP.32?

SGP.32 is the GSMA technical specification for the remote provisioning and management of eUICCs in IoT devices that are network-constrained, user-interface-constrained, or both. The first version was published in 2023. According to the GSMA’s eSIM specification status page, the current active releases are SGP.31 v1.3 and SGP.32 v1.3, dated 22 May 2026, and the SGP.32 v1.3 document went up on the GSMA site on 28 May 2026. Version 1.2 remains active and is still the version most certified eUICCs, eIM platforms and SM-DP+ servers have been tested against, so expect to see both numbers on datasheets for a while.

In standards language that all sounds rather dry. In practical terms it answers a much more interesting question: how do you change the mobile subscription in a device when there is nobody there to do it? The answer rests on two components, the IoT Profile Assistant and the eSIM IoT remote Manager. Understand those and you understand most of the difference between SGP.22 and SGP.32.

LPA vs IPA: from the consumer’s hand to the IoT device

SGP.22 uses the Local Profile Assistant. SGP.32 introduces the IoT Profile Assistant, or IPA. The IPA handles the device-side job of fetching and installing profiles, but it sits inside an architecture where remote instruction, not local human interaction, is the starting point. It can be implemented in two ways:

• IPAd lives in the IoT device, typically in the module or host firmware. It suits devices with enough processing headroom, such as routers and gateways, where the manufacturer wants device-side control.
• IPAe lives inside the eUICC itself. The device needs far less awareness of the provisioning process, which suits very constrained endpoints and, crucially, existing hardware.

The IPAe option is particularly significant for the installed base. Putting the profile assistant into the eUICC means SGP.32 capability can, in the right circumstances, reach a device without the device being redesigned around it. A SIM can look exactly like an ordinary plastic card and still carry far more capability than the card it replaces. We looked at this in practice in Robustel, Kigen and the plastic eSIM, where moving the intelligence into the card changes the economics of upgrading an existing router estate.

The eIM: the other half of SGP.32

If the IPA is the device-side capability, the eSIM IoT remote Manager, or eIM, is the remote orchestration. This is where SGP.32 becomes genuinely interesting for enterprises. The eIM sends profile operations to the eUICC: trigger a download, enable a profile, disable one, delete one. An eUICC is associated with an eIM, and that association can be set up at manufacture or later in the device’s life.

The mental model shifts completely. Consumer eSIM is essentially:

SGP.32 becomes:

The person next to the device has gone. More importantly, managing one device at a time can go too. An organisation can build processes around fleets. A manufacturer can ship one common product into many markets and provision connectivity later. A utility can manage operator profiles across thousands of deployed endpoints from a single console. A global IoT provider can change the connectivity behind devices to meet commercial, regulatory or operational needs. That is a far more natural architecture for IoT.

SGP.22 and SGP.32 side by side

In SGP.22, the person and the local device experience are part of the provisioning journey. In SGP.32 the centre of gravity moves to remote lifecycle management. For IoT, that is the breakthrough.

Where the SM-DP+ fits

One component appears in both architectures: the Subscription Manager Data Preparation Plus, or SM-DP+. It securely prepares, stores and delivers operator profiles, and SGP.32 deliberately reuses it from the consumer model rather than inventing something new. That reuse is one reason the IoT ecosystem has been able to build on infrastructure operators already run.

It is also a useful reality check. SGP.32 does not turn every enterprise into a mobile operator. The profile still has to come from an operator or connectivity provider, and the eUICC still needs valid credentials to authenticate to a network. The innovation is in how those profiles are delivered and managed across the life of the device. SGP.32 creates flexibility around connectivity. It does not conjure coverage out of thin air, and it does not remove the need for commercial agreements with network providers.

SGP.32 does not mean “connects to every network”

This is the misconception worth killing early. SGP.32 is sometimes described as though an SGP.32 SIM magically becomes an all-network SIM. It does not. Two separate concepts are getting mixed up: roaming and remote profile provisioning.

A traditional multi-network IoT SIM carries a subscription from one home network or connectivity provider. Through roaming agreements, that single subscription can attach to several visited networks. In the UK, a suitably provisioned roaming IoT SIM might reach EE, O2, Vodafone and Three, but it is still using its existing credentials. Changing the operator profile is different. With SGP.32, a new profile can be downloaded to the eUICC, so the device moves from:

Those are not the same thing. Our explainer on why multi-network SIMs do not always switch to the best network covers how network selection, forbidden network lists and operator steering really behave. SGP.32 adds another tool to that picture. It does not make those considerations disappear.

Why this matters for UK IoT connectivity

Suppose a business deploys 20,000 connected devices across Britain and chooses Connectivity Provider A. Everything works. Five years later, plenty could have changed. The commercial terms may no longer be competitive. Coverage needs may have shifted. One network may perform badly in an important part of the estate. The provider may have changed hands, a roaming agreement may have lapsed, new network technology may be available, or the organisation may simply have negotiated a better deal elsewhere.

With conventional SIMs, changing supplier means changing physical SIMs, and across 20,000 deployed devices that wipes out the saving. Knocking £1 per device per month off the bill sounds wonderful until someone has to visit 20,000 cabinets. Remote profile provisioning changes that arithmetic. The connectivity contract and the physical deployment no longer have to be welded together for life.

SGP.32 changes what “future-proof” means

“Future-proof” is abused mercilessly in technology marketing, and nothing truly is. But SGP.32 tackles one specific long-term risk very well: the subscription chosen at deployment no longer has to be the subscription the device dies with. For hardware expected to run for ten or fifteen years, that is significant.

Think how much UK mobile connectivity has changed since 2011. Networks have merged. Brands have vanished. 3G has been switched off and 2G has a closure date. 4G became ubiquitous, 5G arrived, LTE-M and NB-IoT appeared, private networks spread, roaming relationships shifted and IoT connectivity providers consolidated. Nobody deploying a device today can confidently predict the market of 2036. The rational response is not to predict perfectly. It is to keep your options open, and SGP.32 is fundamentally about keeping options open. It is the same long-life problem we explored in the fifteen-year IoT challenge, applied to the SIM.

Does SGP.32 eliminate operator lock-in?

It can reduce it considerably. It does not eliminate it automatically. A standards-compliant architecture can still be wrapped in a commercial proposition that makes leaving difficult, so an enterprise evaluating SGP.32 should ask far more than “does this support SGP.32?”:

• Who controls the eIM, and can the eUICC be moved to a different eIM?
• Who provides the bootstrap connectivity, and on what terms?
• Which SM-DP+ platforms are supported?
• Which operator profiles can actually be downloaded, and can a different provider’s profiles be introduced?
• What happens to the estate if we terminate the contract?
• Who owns the operational data?
• What is charged per profile download, switch or deletion?
• What happens if a profile change fails part-way?

That is the difference between buying eSIM technology and buying commercial freedom. The two are not automatically the same thing.

SGP.32 and the bootstrap problem

Remote provisioning has a pleasingly circular problem: to download connectivity, you generally need connectivity. An IoT device therefore needs an initial route to start the process, usually called bootstrap connectivity. The device leaves the factory with an initial profile that gives just enough network access to reach the provisioning infrastructure, and once deployed the operational profile is downloaded.

That enables an attractive manufacturing model. Instead of building separate UK, German, French, US and Australian variants, each with its own SIM supply chain, a manufacturer can move towards one globally deployable device, with bootstrap connectivity and local profile provisioning in the field. That simplifies logistics and removes the risk of expensive stock sitting in a warehouse with the wrong operator credentials embedded in it. It also explains why the choice of bootstrap provider deserves as much scrutiny as the operational connectivity: it is the first link in the chain.

Why SGP.32 matters for permanent roaming

Permanent roaming has powered a huge share of international IoT. A SIM issued under one network’s identity is deployed in another country and stays there, roaming on a partner network indefinitely. It is technically elegant and commercially useful, and regulators do not always like it. Some countries restrict or discourage permanent roaming outright, and operators can change their own rules.

SGP.32 offers another strategy. Instead of leaving the device roaming forever, a suitable local operator profile can be downloaded after deployment, so the device becomes a genuine subscriber of that network rather than a permanently roaming visitor. That does not mean every SGP.32 service offers local profiles in every country; the commercial agreements still matter. But the architecture makes the model possible without swapping the physical SIM.

What SGP.32 means for multi-network IoT SIMs

This is where the next few years get interesting. Today’s multi-network IoT SIM solves a real problem: rather than relying on one UK radio network, a roaming subscription can use several, which improves deployment flexibility and coverage resilience. SGP.32 does not make that model redundant. The strongest proposition may combine the two. Imagine an eUICC holding:

• Profile A, a roaming subscription with broad multi-network access;
• Profile B, a local UK operator profile;
• Profile C, an alternative international connectivity provider.

The device is no longer just choosing between the radio networks one subscription allows. The organisation can change the subscription itself. That gives two layers of resilience:

That is a substantially more powerful connectivity model than either approach alone. For context on where today’s multi-network and roaming SIM offers sit, our look at unlimited, multi-network and public IP IoT SIM cards covers the current options.

SGP.32 does not fix poor RF

Every new networking technology risks being presented as the answer to problems it has nothing to do with. SGP.32 cannot fix a bad antenna. It cannot create 4G coverage inside a sealed metal enclosure, push 5G into an underground plant room, compensate for a badly installed router or relieve congestion on the serving cell. Switching profiles only helps if another suitable network is actually available at the site.

IoT connectivity still starts with RF engineering: a decent antenna, sensible placement, the right band support and a clear view of which networks are present where the device will live. eSIM changes how connectivity is provisioned. It does not repeal physics.

SGP.22 still has a place in IoT

After all this, it would be easy to conclude SGP.22 is somehow bad for IoT. That would be wrong. There are IoT devices where it works perfectly well, and industrial routers are the obvious example. A modern router runs a full Linux-based operating system, has a web interface and cloud management, and has enough processing headroom to handle profile management comfortably.

Teltonika’s current eSIM routers illustrate this transitional market well. The RUTM30, for example, uses a consumer-type SGP.22 eSIM that can hold several profiles, and the Teltonika RUTM30 eSIM manual shows the consumer heritage clearly: profiles are added with an activation code or QR code image, through the router’s own interface, and the router needs another working WAN connection to download one. That is not a criticism. It provides genuinely useful remote provisioning today, especially when paired with a vendor cloud platform. It is simply a different model from SGP.32.

What matters is that buyers understand what they are getting. “Supports eSIM” is no longer a sufficient specification. Ask:

• Does it use SGP.22 or SGP.32?
• Where does the profile assistant live?
• How are profiles managed remotely, and can that be automated across a fleet?
• Is a vendor-specific cloud required, and what happens if we stop paying for it?
• Can third-party operator profiles be loaded?

Those questions reveal far more than the word eSIM on a datasheet.

SGP.32 and constrained IoT

SGP.32’s real strength shows as devices get smaller and simpler. The GSMA designed it explicitly for devices that are network-constrained and/or user-interface-constrained, which covers exactly the endpoints that make IoT economically interesting:

• smart meters and utility telemetry;
• environmental and agricultural sensors;
• asset and vehicle trackers;
• alarm systems and remote monitoring equipment;
• LTE-M and NB-IoT endpoints running on batteries.

Compared with these devices, a smartphone has enormous resources. Many IoT endpoints spend most of their lives asleep because the radio is one of the biggest drains on a small battery. SGP.32 reflects that: it supports lighter-weight transport options for constrained links, does not depend on SMS in the way SGP.02 often did, and lets the eIM work within a device’s wake-and-sleep pattern. The connectivity architecture finally accommodates the device instead of pretending it is a tiny telephone.

The hardware reality in 2026

There is a complication for anyone buying equipment this year: the standard can be ready before all the hardware is. SGP.32 v1.3 is an active GSMA specification, but that does not mean every router advertised with eSIM supports native SGP.32. A whole ecosystem has to mature and interoperate: eUICC makers, cellular module makers, device manufacturers, SM-DP+ operators, eIM providers, mobile operators and IoT connectivity providers.

The good news is that SGP.32 has clearly moved beyond theory. Secure element vendors are shipping certified parts; STMicroelectronics, for instance, lists its ST4SIM-300 eSIM for IoT as certified against GSMA SGP.32 v1.2. Interoperability has been tested in the open too. In Kigen’s SGP.32 reality check, devices fitted with plastic eUICCs, each running an IPA connected to Kigen’s eIM, were switched remotely between several connectivity providers’ profiles in a live multi-vendor test.

Even so, verify exactly what a given device and service support. Do not buy a product because a brochure says “next-generation eSIM”. Ask for the specification number, the version, and the certification.

Kigen’s role

One name comes up repeatedly in the SGP.32 ecosystem. Kigen develops eSIM and iSIM technology, was closely involved in shaping the IoT eSIM architecture, and built one of the first certified eIM platforms. Our profile of Kigen and the SGP.32 revolution covers the company, its technology and its part in moving the specification into commercial deployments. It is worth reading because the useful question has changed. It is no longer “what does the GSMA document say?” but “who has implemented it, tested it and built a commercial service around it?”

Can existing IoT devices use SGP.32?

Potentially, and this may become one of the most important parts of the transition. The obvious picture of eSIM is an eUICC soldered into new hardware. That is excellent for new designs, and much less help if you already have 50,000 perfectly good routers in the field.

A removable eUICC with the IPA built in changes that. It packages SGP.32 capability in a familiar SIM form factor, so compatible existing hardware may be able to take part in the newer architecture. The migration path becomes:

rather than ripping out every router and deploying new eSIM hardware. Across a large estate, that difference can be worth millions of pounds. Compatibility is not universal, because the modem and firmware still need to support the SIM toolkit features the card relies on, so test before you commit. But it does mean SGP.32 should not be thought of purely as a feature of the next generation of routers. Some of its biggest commercial impact may come from what can be inserted into hardware that is already deployed.

SGP.22 vs SGP.32: which should you choose?

There is no universal answer, but there is a useful rule of thumb. For a user-operated device with a capable interface, SGP.22 may be entirely appropriate. For a large estate of unattended devices, SGP.32 is much closer to the architecture most organisations have been waiting for.

SGP.22 can make sense when the device behaves like a consumer device

• a capable router or gateway with a rich operating system;
• a product where local user interaction is acceptable;
• a deployment already integrated with a manufacturer’s eSIM management platform;
• a relatively small estate where provisioning devices individually is manageable.

Design towards SGP.32 when the deployment behaves like infrastructure

• large fleets of unattended devices;
• long deployment lifetimes and expensive site visits;
• international deployments or permanent-roaming exposure;
• NB-IoT or LTE-M endpoints with limited interfaces;
• a need to change connectivity provider later, or reduce dependence on one operator.

The more expensive it is to reach the device, the more valuable remote profile management becomes. A £5 sensor on a remote pumping station can create a £300 problem if changing its SIM needs an engineer and a van. The SIM was never the expensive part. The person sent to replace it was.

What should businesses specify today?

If you are planning a significant cellular IoT deployment now, writing “eSIM required” into a tender is no longer enough. A better specification establishes:

1. which GSMA remote provisioning specification is supported, and which version;
2. whether SGP.32 support is native or delivered through another implementation;
3. whether the IPA is device-based (IPAd) or eUICC-based (IPAe);
4. which eIM controls the estate, who operates it, and whether it can be changed;
5. whether alternative operator profiles can be introduced;
6. what bootstrap connectivity is provided, and by whom;
7. what happens when a profile download fails, and whether the previous working profile is recovered automatically;
8. which eUICC form factors are available;
9. which radio technologies are supported, including LTE-M and NB-IoT where needed;
10. what APIs exist for automation;
11. how profile operations are charged;
12. what happens at contract termination, and whether the estate can be migrated to another provider.

That last point deserves particular attention. If the technology designed to remove lock-in creates a new form of platform lock-in, you have merely moved the padlock.

SGP.32 is really about the life of the device

The easiest mistake is to see SGP.32 as a better way of activating a SIM. That undersells it. Initial activation is the start of an IoT deployment, not the hard part. The hard part is year seven. The device manufacturer has changed. The network has changed. The connectivity contract has changed. Some devices are still in Britain; others have been exported. One operator has excellent coverage where you need it, another has raised prices, a country has changed its permanent-roaming rules, and the person who designed the deployment left the company four years ago. Meanwhile 30,000 devices are still quietly doing their jobs.

That is the environment SGP.32 is designed for. It turns connectivity from something decided at manufacture into something that stays manageable for the operational life of the product, which is a much bigger change than swapping a plastic SIM for a chip.

The bigger change: separating the device from the network decision

For most of cellular IoT’s history, three decisions were tangled together: which hardware to deploy, which SIM to install, and which connectivity provider to use for the life of the device. That made sense when changing the third answer meant physically changing the second. SGP.32 begins to separate them. A device can be manufactured before its final operator is known, deployed before its long-term connectivity is fixed, and moved to a new subscription when commercial terms, regulation or coverage change. A global product can increasingly be one hardware platform rather than dozens of connectivity-specific variants.

That is why SGP.32 vs SGP.22 matters far more than another version number in an eSIM standard. SGP.22 made downloadable SIM profiles practical for people. SGP.32 is making them practical for machines, which is arguably where remote provisioning was needed most in the first place.

For UK businesses planning connected products today, the lesson is simple. Stop asking whether a device supports eSIM. Start asking which eSIM architecture it supports, who controls it, and how much freedom it gives you over the lifetime of the deployment. Those answers will matter long after the hardware that won the tender has been forgotten.

IoT UK is an independent technology publication. It is not affiliated with the former government-funded IoTUK programme, Digital Catapult, Future Cities Catapult or Innovate UK. Specification versions and product support are as at October 2026; check the GSMA and manufacturer sources before specifying hardware.