SGP.32 Compliant? 6 Questions to Ask Your IoT eSIM Provider
Mikk Lemberg
"We have IoT eSIMs that are SGP.32 compliant."
Your connectivity provider will say this, and it will be true. It's also almost meaningless — and the gap between those two facts is where device fleets get stuck.
You build devices — robots, scooters, trackers, meters. The next generation ships with IoT eSIM, because the SGP.32 promise is real: no physical SIM logistics, no vendor lock-in, profiles switched over the air across your whole fleet. But whether your fleet keeps that freedom isn't decided by the standard. It's decided by configuration choices and contract terms you'll never see in a sales deck — and they surface during rollout, when your devices are in the field and switching costs are at their highest.
M2M eSIM, the previous standard, already disappointed a generation of IoT teams this way. SGP.32 fixes the technical problems. The commercial ones moved into the fine print.
Full disclosure: 1oT is a connectivity provider, so we have a stake in this game. This is the list we think you should run on us — and on everyone else at the table. Six questions. The last one is the one almost nobody asks.
Short on time? Skip to the downloadable checklist here
The stack behind "compliant," in 60 seconds
When a provider says "SGP.32," they're making a claim about four components at once:
Your provider may own some of these and rent others. Each one has a way of quietly taking back the freedom SGP.32 gave you. Hence the six questions.
1. Can my devices download profiles from any GSMA compliant SM-DP+?
This is the core promise of the standard: switch operators over the air, no SIM swap. But some providers configure or contract their way around it by whitelisting which SM-DP+ addresses your eUICCs can reach — often just the one they control.
Here's what that looks like in practice. The profile exists. The eUICC has capacity. The eIM works. And the download is refused, because the new profile sits on an SM-DP+ that isn't on the list. On paper you have switching freedom; in practice you can only switch to whatever your provider sells.
Teams usually discover this in the service agreement — or worse, in the field.
Ask the follow-ups too: is the restriction technical or contractual? For how long does it apply? A good answer names external SM-DP+ platforms they've downloaded from in production, or puts the whitelist policy in writing. "That's on the roadmap" is not a good answer.
2. If I leave you, can my fleet come along?
Your devices get bound to the provider's eIM when they're deployed. Some configurations make that binding permanent — the eUICCs will never accept commands from another eIM.
In the ideal world you never need this. But play out the scenarios: your provider raises prices 300% at renewal. They have repeated outages. Your company gets acquired and needs to consolidate platforms. If your eUICCs can't be re-associated with a third-party eIM, you're not negotiating any of those situations — you're accepting them.
There's no technical requirement for this lock. It's a commercial choice.
Ask: can these eUICCs be re-associated with a different eIM after deployment? What's the process, and what does it cost? There are three specific operations to get confirmed in writing — addEim, deleteEim, and updateEim — and they deserve their own post, coming next. For now: if the provider goes vague when you name them, you've learned something.
3. Can I delete the bootstrap profile once I've moved on?
Every eUICC ships with a bootstrap profile — the pre-loaded connectivity it uses to connect the first time. Reasonable. What's less reasonable: some vendors configure that profile as non-deletable, sometimes with a subscription cost still attached to it.
The result is quiet and expensive. You switched providers two years ago, and you're still paying rent to the old one on every single device.
Ask: is the bootstrap profile deletable post-deployment? Are there ongoing costs tied to the bootstrap subscription? This one takes thirty seconds and the answer is either yes or no.
4. Will you work with eUICCs I source myself?
You manufacture the device. At some point you'll want to choose the chip — a manufacturer with better pricing, a second source for supply security, an iSIM roadmap. Some providers only manage eUICCs that ship with their bootstrap profile. You're locked into buying chips through their channel, forever.
There's a hardware-side version of this trap too. We've seen a prospect with a chip already soldered onto their hardware, marketed as SGP.32, legitimate GSMA certification and all. No IPAe on the card, so the eIM had nothing to talk to on the device side. The docs mentioned a "trusted connectivity partner" — no name, no contact, just a line in a datasheet. Certification means the chip can store profiles. It doesn't mean anyone can actually operate it.
Ask: which eUICC manufacturers do you support without requiring your own bootstrap profile? And before you commit: get a live demo of a profile download on your actual hardware. A datasheet won't tell you there's no eIM to log into.
5. Which vendors have you actually tested with — in production?
This is where the gap between the spec and reality is widest. GSMA left vendors flexibility in certificate management and TLS configuration. Good for security diversity, brutal for interoperability.
The pattern we keep seeing: a customer downloads profiles fine using one vendor's eUICC, eIM, and SM-DP+ together. Then a download from an external SM-DP+ fails. Every time. Everybody involved is SGP.32 compliant. They've just never actually tested together — each vendor's setup works beautifully in its own ecosystem and falls over at the boundary, usually on certificate validation.
And when it fails, the troubleshooting is a nightmare with four suspects: the device, the eSIM infrastructure, the network, the certificates. Opaque error codes, unclear ownership, weeks of stalled rollout while vendors point at each other.
Ask two things. First: which eUICC manufacturers and external SM-DP+ platforms have you shipped with in production — real customer deployments, not lab environments? Second: when a cross-vendor profile operation fails, what's your troubleshooting process and who owns the resolution?
Providers who've done this work will name names. Providers who haven't will talk about standards compliance and roadmaps.
6. If I switch providers, what happens to my operations?
The question almost nobody asks, because it lives on a layer the eSIM sales conversation never touches.
SGP.32 moves the profile. Your team lives in the CMP — the platform where SIMs get activated, usage gets monitored, limits get set, alerts fire when a device in Turkey goes dark. That platform is wired into your internal tools, your workflows, your on-call habits.
Now switch connectivity providers. The profile moves over the air, exactly as promised. But if the new provider means a new CMP, you're re-integrating APIs, rebuilding alert rules and usage limits, losing historical data, and re-onboarding your whole ops team. The eSIM moved. Your operations didn't.
Ask: which connectivity providers does your CMP integrate with? What data and configuration is portable if we part ways? Is there full API access for our own integrations?
Then run this pressure test internally: if we had to switch providers in two years, what actually changes — systems, workflows, people — and who owns that migration? If the answer is "everything, and nobody," you've found your real lock-in.
The complete checklist
The right questions today can save years of lock-in tomorrow. Ask better questions, document every answer, and make decisions based on facts, not sales pitches.
We turned this into a fillable PDF you can bring into the actual vendor call — one copy per vendor, with space to mark each answer as verified in writing, verbal only, or dodged.
Straight answers are the tell
None of this is a reason to avoid IoT eSIM. Remote provisioning is real, it works, and it's transformative for device fleets. But plan for the ideal and architect for the exit.
The providers who answer these questions directly are telling you something. So are the ones who dodge, defer, or reach for the roadmap. In our experience, the teams who get this right ask the hard questions early, run POCs under production conditions, and put optionality in the contract. They're the ones who won't be stuck three years from now with a hundred thousand devices they can't migrate.
This is the list we hand our own prospects. Ask us these questions — then ask everyone else the same ones. If you want to go through them with an engineer rather than a salesperson, talk to us.
.avif)
.avif)
.avif)
