If you've spent any time around IoT connectivity, you've probably seen these three codes thrown around like everyone just knows what they mean: SGP.02, SGP.22, SGP.32. 

These GSMA specifications define how operator profiles are remotely provisioned and managed on eUICCs — each built around a different device reality that shapes where provisioning happens, who controls the eUICC, how profiles are delivered and managed, and how easily you can scale.

And that matters when you’re choosing one. The question isn’t “which spec is newest?” It’s “which architecture actually fits my deployment?”

_{1. What is SGP.02: the original spec for screenless M2M devices}

SGP.02 was the GSMA's first Remote SIM Provisioning standard, built to address a very practical M2M (Machine-to-Machine) problem: how do you provision and manage a telecom profile on a device you can’t, or really don’t want to, physically access?

With a traditional SIM, changing operators meant physically getting to the device and swapping the card. Fine for one device. Not ideal when you have thousands of them deployed across the field.

And even more so when your device is a smart meter buried underground, a wellhead two hours from the nearest paved road, or an oilfield sensor sitting miles offshore.

SGP.02 flipped that model: install the eUICC once, then manage its telecom profiles remotely for the device’s lifetime. At least, that was the promise.

The architecture splits provisioning across two servers:

• SM-DP (Subscription Manager – Data Preparation): prepares and encrypts the telecom profile
• SM-SR (Subscription Manager – Secure Routing): securely delivers the profile to the device and manages it over its lifetime
• MNO (Mobile Network Operator)
• EUM (eUICC Manufacturer): produces the eUICC and permanently configures it with the SM-SR at manufacturing time
• eUICC, also known as SIM card

The SM-SR acts as the remote manager for the eUICC. It knows how to communicate with the device, establishes secure channels, manages lifecycle operations, and coordinates profile downloads.

_{How the profile transaction works}

1. Manufacture-time setup. The SM-SR gets configured onto the eUICC at the factory, alongside a bootstrap profile for initial connectivity. A formal swap exists — control and profile ownership can move to another SM-SR — but it takes the same cross-operator heavy lifting as switching SM-DPs, so in practice it rarely happens.
2. Profile preparation. The SM-DP preps and encrypts the operator profile.
3. Delivery. The SM-SR sends a secure SMS telling the eUICC to open a management session. Depending on the implementation, the eUICC then establishes either an HTTPS session or a CAT_TP session over a BIP channel.
4. Download and installation. The profile package travels from the SM-DP through the SM-SR to the eUICC over that session. The eUICC installs it into a dedicated security domain and reports back the result.
5. Lifecycle management. The SM-SR handles enabling, disabling, and deleting the profile for as long as the device is out in the field.

But here’s the catch: want a profile from another telecom? The SM-SR can only get it from an SM-DP it’s already integrated with. That requires a commercial agreement between competing operators that makes it easier for customers to walk. Not exactly an easy sell.

SGP.02 also relied on SMS to trigger profile downloads, which is fine for a cellular-connected industrial gateway but not so much for low-power networks like NB-IoT, where devices might only wake up to send a few bytes a day.

Bottomline: technically the standard allowed the remote profile switching. But the market mostly kept it from happening.

SGP.02 was the first implementation of remote SIM provisioning, built to tackle a very real problem with the technology available at the time. It made remote profile management possible, but its architecture came with enough constraints that remote provisioning didn’t always hold up in real-world deployments.

_{2. What is SGP.22: the consumer eSIM} 

SGP.22 is the GSMA standard for consumer remote SIM provisioning architecture, and it was designed around a very different assumption than SGP.02: that a human is there, holding the device, ready to tap a button or scan a QR code.

It's the standard you've unknowingly used if you've ever scanned a QR code from a travel eSIM app before a trip. 

SGP.22's real achievement is that it decouples the profile from the hardware. No more operator lock-in baked in at manufacture. You, the user, can choose a telecom and then switch it later, entirely over the air. 

The architecture simplifies SGP.02's two-server split into one:

• SM-DP+: combines the data-preparation and secure-routing roles into a single server that both packages and delivers the profile
• LPA (Local Profile Assistant): lives on the device (or partly on the eUICC) and drives the whole process: scanning the QR code, talking to the SM-DP+, installing the profile, and letting the user enable, disable, or delete profiles
• SM-DS (Subscription Manager – Discovery Service): an optional directory service that helps the LPA find the right SM-DP+ when the operator wants to push a profile without a QR code to scan

Unlike the other two, this is a pull model: the device (via the user) initiates the download. It's built on HTTPS/TLS, which is heavyweight compared to what a battery-powered sensor can afford, but perfectly reasonable for a smartphone with a modem and a screen.

_{How the profile transaction works}

1. Trigger. A person uses an activation  code — usually in the form of a QR code they scan — or the LPA gets a nudge from a carrier-initiated push.
2. Discovery (optional). No QR code? The LPA asks the SM-DS where to look.
3. Authentication and download. The LPA talks to the SM-DP+ over HTTPS/TLS, proves who it is, and pulls down the encrypted profile.
4. Installation. The LPA installs it onto the eUICC.
5. Lifecycle management. From here, it's entirely up to the user — enable, disable, delete, or grab a different profile, whenever they feel like it.

SGP.22 is mature, broadly certified, and extremely well supported across the industry. The problem arises the moment you try to point SGP.22 at IoT: what happens when your "user interface" is a sensor bolted inside a shipping container with no screen, no buttons, and a network connection that shows up for thirty seconds a day? 

For years, IoT companies duct-taped SGP.22 into service for deployments it wasn’t designed for. If you had the engineering muscle, that could actually work in your favor: build your own device-side logic, bootstrap connectivity and provisioning orchestration, giving you more control over how the whole thing worked. But it also meant more moving parts to keep aligned, and things could get messy pretty quickly when one of them went sideways.

Overall, it’s still the best fit for devices with a screen and a person behind the controls. For anything headless, we wouldn’t recommend it.

_{3. What is SGP.32: the one actually built for IoT}

SGP.32 is the GSMA standard for IoT Remote SIM Provisioning, published in May 2023. It answers a question the industry had been waiting a long time to see addressed: what if we built an eSIM standard for headless, constrained, fleet-scale devices instead of forcing one of the other two to do a job they weren’t designed for?

Rather than starting from scratch, SGP.32 cleverly keeps what worked and swaps what didn't:

• eUICC: the embedded chip that stores and runs profiles. Physically unchanged in principle from SGP.02/SGP.22 eUICCs, but running IoT-specific logic such as managing eIM associations and securely receiving and executing remote profile-management operations.
• EUM: the eUICC manufacturer. Companies like Kigen, Thales, G+D, and Idemia. Produces the chip and, critically, performs the initial eIM binding at manufacturing time.
• SM-DP+: unchanged from SGP.22, because the new eIM/IPA layer handles the IoT side while the SM-DP+ keeps doing what was already doing well.
• IPA (IoT Profile Assistant): the LPA’s counterpart on the device or eUICC side, responding to the eIM instead of a person.
• eIM (eSIM IoT Remote Manager): a cloud-based orchestration layer that does the LPA's (Local Profile Assistant) job without waiting for a tap. It pushes download, enable, disable, and delete commands across a single device or an entire fleet
• SM-DS: same discovery role as SGP.22

SGP.32 reuses the SM-DP+ in consumer eSIM, so operators don’t have to build a separate profile-preparation system from scratch. They can keep the infrastructure and expertise they already have and plug it into the new IoT architecture – that existing foundation made SGP.32 much quicker to roll out.

_{How a Profile Transaction Works}

1. Bootstrap — at the factory. Before manufacturing even starts, the connectivity provider sends the required profile data to the EUM. The EUM loads the bootstrap profile onto the eUICC and associates it with the provider’s eIM. 
2. Trigger — out in the field. Once deployed, the device checks in with the eIM, typically through periodic polling, with event-driven triggers such as a restart or network reattach providing additional opportunities to check for pending work.
3. Download — get the next profile. When the device needs something beyond its bootstrap profile, the eIM initiates the profile download with the SM-DP+. The transaction can be direct, with the device handling its own authentication, or indirect, where the eIM handles that interaction on the device’s behalf — useful for constrained hardware that can’t comfortably carry the full stack.
4. Installation — into the eUICC. The IPA receives the Bound Profile Package and passes it to the eUICC for installation.
5. Lifecycle management — fleet-wide control. The eIM can issue PSMO commands to enable, disable or delete profiles, targeting individual eUICCs or an entire fleet.
6. Operator flexibility — where SGP.32 gets interesting. If you want to move a device to a different provider, ECO commands — addEim, deleteEim and updateEim — allow the eUICC’s eIM configuration to be changed. The standard defines the mechanism; whether your provider actually lets you use it is a separate commercial question.
   

_{3.1. SGP.02 VS SGP.32: What exactly changed}

SGP.32 directly tackles the two biggest things that made SGP.02 a tough fit for IoT at scale:

• Drop the SM-SR: SGP.32 removes the SM-SR from the architecture. The eUICC works with the SM-DP+ through the IoT Profile Assistant (IPA), while the eIM handles remote management. That removes the tight SM-SR/SM-DP coupling that made cross-operator provisioning in SGP.02 dependent on pre-established relationships.
• Drop the SMS dependency: instead of using SMS to trigger profile downloads, SGP.32 uses IP connectivity between the device, IPA, eIM and SM-DP+. That fits IoT devices much better, especially where connectivity is constrained or intermittent.
• Push or pull: SGP.32 supports both eIM-triggered and device-initiated downloads, so a profile can be pushed to a device or pulled when the device is ready.

SGP.32 also brings CoAP over UDP with DTLS, a lightweight alternative to HTTPS/TLS that sip data and power instead of gulping them, which matters a lot for NB-IoT or LTE-M devices working with kilobyte-scale daily data budgets. 

Think of it this way: SGP.32 fulfills SGP.02's original vision of remotely provisioning and managing headless devices, but with an architecture that doesn't choke on constrained hardware or low-power networks, along with SGP.22's flexibility for operator switching. 

The technical lock-in is gone. But there’s a different kind of lock-in you should watch out for.

_{3.2. The other layer of lock-In}

SGP.32 removes one of SGP.02’s biggest architectural constraints: the eUICC is no longer tied to an SM-SR with pre-established relationships to specific SM-DPs. The technical barrier to profile switching is gone.

But here’s where it gets tricky: technical portability doesn’t necessarily guarantee commercial portability.

The spec makes eIM switching a requirement for the eUICC, but not for the eIM. The eUICC has to support adding, removing, and updating eIM associations. The eIM, on the other hand, is only allowed to support those things — GSMA doesn’t say it has to. So the chip in your device is technically ready to talk to a new eIM. Whether the eIM your vendor gave you will actually let you add one is a different question. 

That’s where the commercial lock-in kicks in.

Instead of the architecture saying “you can’t switch,” the contract can say “you can switch, subject to…” Minimum commitments. Profile restrictions. Network-access conditions. Volume tiers. Termination fees. External SM-DP restrictions. Whatever makes leaving painful enough to make you reconsider.

The takeaway? Before you sign an IoT connectivity contract, don’t just ask whether the platform supports SGP.32. Ask what you can actually do with that flexibility once you’re a customer.

If you’re comparing providers, make sure to ask the right questions before you commit: what happens when you want to use an external SM-DP+, move your eUICCs to another eIM, remove the bootstrap profile, bring your own eUICCs, connect components from different vendors, or just decide to walk away altogether.

We’ve put together a free downloadable checklist covering the questions we’d want answered before signing an IoT connectivity contract.

[Download the IoT Connectivity Vendor Lock-In Checklist]

At 1oT, though, we don’t play that game. We believe the technical flexibility SGP.32 enables should actually translate into commercial flexibility, and we don’t put contractual handcuffs on technical flexibility.

Besides, you get access to an all-in-one platform to manage your IoT connectivity — all your connected devices, SIMs, and telecom providers in one place, with a single invoice.

Ready to give SGP.32 a try? Request your test kit today 👇

_{4. SGP.02, SGP.22, and SGP.32: When to Choose Each One}

This is the part that matters most, so here's the decision logic, no fluff:

• When to choose SGP.22: if your device has a screen, a user, or any scenario where a human intentionally installs or swaps a profile – phones, tablets, wearables, travel routers with a companion app. SGP.22 is mature, extremely well supported by carriers, and there's no good reason to fight it for consumer-facing hardware.
• When to choose SGP.32: if you're deploying headless devices at any real scale – asset trackers, smart meters, industrial sensors – anything that will sit in the field for years without anyone physically touching them (especially over NB-IoT, LTE-M, or other power-constrained networks). This is the standard built for exactly that problem.
• When to consider SGP.02: mainly if you're maintaining an existing deployment that already runs on it – automotive is the classic example, along with other long-lifecycle, factory-provisioned systems that aren’t realistically touched after rollout. But be aware the industry is actively moving off it, and greenfield M2M/IoT projects have very little reason to start here today. 

_{4.1. SGP.02 vs SGP.22 vs SGP.32: A Head-to-head Comparison}

_{4.2. What each spec actually costs your hardware}

The architecture diagrams never show you the bill. A modem that has to hold a TLS session instead of napping between check-ins. Flash you didn't budget for because something has to store certificates. A battery curve that looked fine on paper until the device started doing handshakes in the field.

None of that shows up on paper. It shows up three months later, when your hardware engineer asks why the coin cell is draining twice as fast as spec'd.

The spec you pick decides who pays — your factory line, your device's compute budget, or your eIM — and how much say you get in the split. Here's where the bill lands for each one:

‍

The pattern: SGP.02 pushes cost onto manufacturing and network, SGP.22 pushes it onto device compute, and SGP.32 is the first spec that lets you choose how much of that cost the device carries versus offloading it to the eIM

_{Wrapping up}

At the end of the day, there’s no single “best” eSIM spec — there’s the one that fits your deployment. SGP.02 still has its place in legacy M2M, while SGP.22 remains the best option for devices with a screen. And if you’re working on IoT connectivity today, SGP.32 is the one worth digging into.

But the spec is only part of the story. SGP.32 offers technical flexibility, but what you can actually do with that flexibility still depends on your connectivity provider. So before you choose a provider, look beyond the spec and make sure you understand what you’ll actually be signing for.

_{Frequently Asked Questions}

_{Is SGP.32 better than SGP.22?}

No, they're solving different problems. SGP.22 is still the right tool when a human is meant to be in the loop. SGP.32 is better for headless, fleet-scale deployments, which is a different job entirely.

_{Can a single eUICC support more than one of these standards?} 

Not really. A given eUICC implementation is typically built to a specific RSP architecture. What you do see in practice are hybrid setups, like SGP.22-based hardware with SGP.32-style remote orchestration layered on top by a connectivity platform. That was often used as a stopgap before fully SGP.32-native chipsets were available, but it comes with clear limitations.

_{Does SGP.32 replace SGP.02 entirely?} 

No, SGP.02 products are still available to order. SGP.32 doesn't replace it — it fixes the operator lock-in and SMS dependency that made SGP.02 a poor fit for new IoT projects. Most new deployments choose SGP.32 anyway, while SGP.02 mainly lives on in existing rollouts like automotive fleets, where ripping out embedded hardware isn't trivial.

_{Is SGP.32 available yet?} 

Yes, 1oT’s SGP.32 SIMs are available today and are already being used by countless real IoT deployments. 

Unlike with SGP.02, profiles can be downloaded and switched over-the-air without complex operator integrations, so you're never locked to a single connectivity provider and never need to recall devices or swap SIMs.

And the best part: with 1oT, your entire fleet – even eSIMs running profiles from different carriers – is managed in one platform, 1oT Terminal, with a single invoice, one support contact, and one API integration. In a nutshell, carrier flexibility without the carrier overhead.

Testing SIMs are available to order if you want to try them in your setup 👇

_{Do I need to pick one standard and commit to it for the device's entire lifecycle?}

In practice, yes, at the hardware level. The eUICC and its provisioning stack are built to a specific RSP architecture, and you can't retroactively upgrade an SGP.02 eUICC to speak SGP.32. So plan your standard choice around your device's expected lifespan and deployment scale, not just what's easiest to integrate today.

_{Does SGP.32 need HTTPS like SGP.22?} 

It can use HTTPS/TLS, but its real advantage is adding CoAP over UDP with DTLS as a lightweight alternative, purpose-built for devices where every byte and every millisecond of radio-on time costs battery life.