SGP.32 Explained: What the New IoT eSIM Standard Changes, and What to Check Before You Switch

A smart meter installed today will probably still be on the wall in 2040. An EV charger, an asset tracker on a shipping container or a sensor on a power line often lives just as long. The mobile contract that connects it rarely does. Prices change, operators merge, networks get switched off, and a deal that made sense on day one can look very different five years later.

For most of IoT's history, changing the connectivity provider for a device meant changing the SIM card. That's fine for ten devices in an office. It's a serious project for fifty thousand devices spread across a country, many of them on rooftops, inside machines or in places nobody visits twice.

SGP.32 is the GSMA's answer to that problem. It's the new eSIM standard written specifically for IoT, and it's now moving from specification to real products. Here's what it does in plain language, where it helps, where it doesn't, and what to check before you build it into your next device.

What SGP.32 actually is

An eSIM is a SIM that can hold one or more operator "profiles" and receive new ones over the air. The chip itself is called an eUICC. The question every eSIM standard answers is simple: who is allowed to tell the chip to download or switch a profile, and how?

SGP.32 (together with its companion document, SGP.31, which sets out the architecture and requirements) is the GSMA's specification for doing this on IoT devices. That means devices with no screen, no keyboard and nobody standing next to them to press "OK". The GSMA publishes the specification openly, and it has been updated several times since the first version in 2023.

Why the earlier standards weren't enough

There were already two eSIM standards before SGP.32, and IoT teams have lived with the limits of both.

SGP.02, the original M2M standard, puts control in a server run by the operator (the SM-SR). It works, but switching to a new provider usually means the old and new operators have to integrate with each other or hand over control. In practice, that gave the incumbent a lot of say over whether you could leave.

SGP.22, the consumer standard, is what your phone uses. It's flexible, but it assumes a person: you scan a QR code and confirm the download on the screen. A temperature sensor can't do that.

SGP.32 takes the best part of the consumer model (the standard profile servers that every operator already runs) and replaces the person with a remote manager.

How it works, in two pieces

SGP.32 adds two new roles:

The eIM (eSIM IoT remote Manager). A server that you, or a provider you choose, control. It decides which profile each device should use, and can send that instruction to one device or to an entire fleet at once.

The IPA (IoT Profile Assistant). The part that carries out the instructions on the device side. It can live in the device's firmware or inside the eSIM chip itself.

A useful way to picture it: the eIM is the fleet manager, the IPA is the driver who follows instructions, and the profile servers are the petrol stations that every operator already runs. Instructions from the eIM are signed, and the chip verifies them before acting. The messages are also designed to be small, so battery-powered devices on narrowband networks can handle them.

What it changes for you

You can change operator without touching the device. This is the big one. If a contract ends, an operator exits a market or a better offer comes along, the new profile can be downloaded over the air. No site visits, no new SIM cards in the post.

Control sits with the device owner. Because the eIM is chosen by you rather than by the operator that happens to hold your devices today, switching no longer depends on your current provider's cooperation. That changes the balance in a negotiation.

It helps with local rules. Several countries, including Brazil, India and Turkey, restrict how long a device can stay on a roaming connection. A long-term deployment there may need a local profile. With SGP.32 you can add that profile later, country by country, instead of designing a different product for each market.

It suits long-lived, low-power devices. The lightweight messaging was designed with sensors and meters in mind, not phones.

What it doesn't change

SGP.32 is a real step forward, but it's easy to expect more from it than it delivers. Four things are worth knowing before you plan around it.

Your existing devices probably can't be upgraded. SGP.32 needs an eSIM chip that supports it. Chips already in the field on SGP.02 or SGP.22 generally can't be converted by a software update. For most companies, SGP.32 is a decision for the next hardware generation, not a fix for the current fleet.

It doesn't replace good default coverage. A profile that already works across many networks in many countries (often called a multi-network or multi-IMSI profile) gives a device coverage from the moment it's switched on. SGP.32 adds the option to download a different profile later. The two work well together. Many teams will ship with a broad default profile and keep SGP.32 as their long-term exit and flexibility option.

Security moves to a new place. SGP.32 builds on the proven security model of consumer eSIM: profiles are encrypted and tied to one specific chip, and every instruction is signed. What changes is who can trigger a switch. Whoever controls the eIM can move your whole fleet to a different network, so access to it deserves the same care as access to your device management platform.

The market is still maturing. Certified chips, modules and eIM platforms have been arriving through 2025 and 2026, and not every combination has been tested together yet. Analysts at Kaleido Intelligence expect eSIM to pass half of new IoT connections around 2027 to 2028. Early adopters should test the full chain (chip, module, firmware and eIM) before committing to volume.

Five questions to ask before your next hardware design

How long will this device be in the field, and in which countries? The longer the life and the more countries, the stronger the case for SGP.32.

Does the cellular module we're choosing support SGP.32, and where will the IPA run? If it runs in the device, your firmware team needs to plan for it. If it runs on the chip, the device side is simpler.

Who will operate the eIM? You, your connectivity provider or a third party? Make sure you can move it later, or you've only moved the lock-in somewhere else.

What profile will the device ship with? Decide what gives you coverage on day one, and which local profiles you might need later because of roaming rules or cost.

How will we test a profile switch before we need one? Run a real switch on a pilot group, including what happens if the new profile fails. A switch you've never tested is a plan, not a capability.

The bottom line

SGP.32 gives IoT teams something they've wanted for a long time: the freedom to change connectivity over a device's whole life without touching the hardware. It won't rescue devices already in the field, and it doesn't remove the need for good coverage from day one. But for anything you're designing now that needs to run for ten years or more, it belongs on the requirements list. The best time to make that decision is before the first prototype, not after the first contract renewal.