When GSMA released the SGP.32 specification for IoT eSIM, it promised something elegant: eSIM for IoT devices with vendor-agnostic flexibility. No more physical SIM logistics, no vendor lock-in, just clean profile management across your device fleet.
That’s the promise. The reality? More complicated.
As a Chief Product Officer for an IoT connectivity platform, I’ve been neck-deep iin SGP.32 implementations—working with eUICC manufacturers, running interoperability tests, reviewing RFPs from operators and enterprises deploying millions of devices but also guiding smaller teams through their future-looking decisions. Here’s what I’ve learned: the standard promises freedom. Vendors have a dozen ways to claw it back. Configuration choices. Contract terms. Technical constraints that don’t show up until you’re mid-deployment.
I’m not trying to be cynical here. Some constraints are reasonable security measures. Others are genuine technical limitations. But many are simply undisclosed, and teams evaluating vendors don’t know the right questions to ask until it’s too late.
Understanding the ecosystem
Before the gotchas, a quick primer on the players – because the vendor landscape itself is the first hidden complexity.
When you deploy SGP.32, you’re not just buying a SIM chip. You’re integrating three distinct components:
The eUICC – The physical chip in your device. Manufactured by companies like Kigen, Thales, G+D, or Idemia. Stores multiple profiles and might include an IPAe (IPA embedded) that handles the profile download process.
The eIM (eSIM IoT Remote Manager) – The platform that manages your eUICC inventory and orchestrates profile operations. The control plane for your entire eSIM fleet.
The SM-DP+ (Subscription Manager Data Preparation) – The system that generates and delivers eSIM profiles to your eUICCs.
Here’s what vendors don’t emphasize: these three components often come from different vendors, and they need to interoperate flawlessly.
Your eUICC manufacturer might not be your eIM provider. Your MNO might operate their own SM-DP+. And just because two vendors claim SGP.32 compliance doesn’t mean they’ve actually tested together.
The four lock-in traps that look like features
1. SM-DP+ restrictions
Your eUICC needs to connect to an SM-DP+ to download profiles. Some MNOs contractually limit which SM-DP+ addresses your eIM can use.. On paper, you have profile switching freedom. In practice, you can only switch to profiles available on their SM-DP+. If you want connectivity from a provider outside that whitelist, you’re stuck.
2. Post-deployment eIM association locks
Say you deploy 10,000 devices with eUICCs from one vendor, managed through their eIM platform. Later, you want to move to a different eIM – maybe your own, maybe a better platform. You might discover that eUICCs are configured to only accept commands from the original vendor’s eIM. There’s no technical requirement for this. It’s a commercial choice that keeps you paying for their platform.
In an ideal world, everything works and you never need to switch. But what happens when your eIM vendor raises prices 300% at renewal? Or they have repeated outages? Or you get acquired and need to consolidate platforms?
If your eUICCs can’t be re-associated with a third-party eIM, you’re stuck.
3. Third-party eUICC restrictions
The reverse scenario: you have an eIM you’re happy with, and you want to source a new batch of eUICCs from a different vendor.
Some eIM platforms won’t let you add eUICCs from other manufacturers because they don’t provide the bootstrap profile. You’re locked into buying eUICCs with their connectivity.
This matters for multi-year deployments where you want to keep ownership of the eIM and manage everything centrally. What if you need a different bootstrap profile? What if a new manufacturer offers better pricing? Make a wrong decision and you end up managing multiple disconnected systems as you scale, like with the good old SIMs.
4. Bootstrap profile deletion locks
eUICCs ship with a bootstrap profile for initial connectivity, pre-loaded at manufacturing. Some vendors configure these as non-deletable by default.
Sounds reasonable for reliability. But if you need to switch MNOs completely, or if that bootstrap profile becomes inactive, you’re paying for dead weight that can’t be removed because there’s ongoing costs tied to it.
The interoperability minefield
Even when vendors claim they support “any SGP.32 compliant” platform, the testing reality is messy.
GSMA gave vendors flexibility with certificate management – good for security diversity, challenging for interoperability. Different vendors implement TLS differently. Certificate chains that work in one vendor’s test environment fail in production with another’s infrastructure.
I’ve watched eUICCs successfully poll an eIM but fail every profile transaction due to certificate validation issues. Both vendors were “compliant”. Both worked perfectly in their own test environments. They’d just never actually tested together in production.
When a profile download fails, the troubleshooting nightmare begins:
- Terminal/device configuration issue?
- eSIM infrastructure problem?
- Telecom network provisioning?
- Certificate chain mismatch between vendors?
Error codes are opaque, ownership is unclear, resolution takes weeks while your deployment stalls.
The uncomfortable truth: vendor partnerships matter as much as standards compliance. Before committing, ask vendors which specific eUICC manufacturers and eIM platforms they’ve completed full production interoperability testing with.
Questions to ask before you sign
The checklist I use when evaluating vendors:
- Can eUICCs be re-associated with a different eIM platform after deployment?
- Can your eIM platform manage eUICCs from multiple manufacturers?
- Are bootstrap profiles deletable post-deployment?
- Can profiles be downloaded from any SGP.32 compliant SM-DP+, or only specific ones?
- Which eUICC manufacturers have you completed full interoperability testing with?
- What’s the troubleshooting process when profile operations fail?
- What are your contract exit terms?
The path forward
This doesn’t mean SGP.32 isn’t worth pursuing. Remote SIM provisioning is transformative for IoT deployments, and implementations are maturing. But the gap between the spec’s promise and vendor reality is real.
Plan for the ideal, but architect for the exit. Choose vendors who embrace multi-vendor ecosystems, who’ve proven interoperability in production (not just lab tests), and who understand that preventing lock-in is a feature, not a threat.
The teams getting this right ask hard questions early, run thorough POCs with production scenarios, and build contract terms that preserve optionality. They won’t be stuck three years from now with millions of devices they can’t migrate.
I’m still learning – the technology is evolving, vendors are improving, new challenges emerge with each deployment. If you’re on this journey too, I’d love to hear what you’re discovering.
Guest Blogs are written by carefully selected Experts. If you also want to create a Guest blog then Contact us.