Welcome to the eSIM IoT market! You will find a number of vendors in the eSIM IoT plaza right now and a lot of the product offers are behind a curtain – at least their full scope. So, once you get the opportunity to see behind the curtain, these are the questions to ask, to ensure you are getting the eSIM IoT solution that fits your needs.
These questions ensure that you get maximum transparency, direct answers on the capabilities of the solution, and a future-proof solution. Alongside every question, you will find example answers that should prompt further investigation from your part and example answers that are green flags and demonstrate a tested solution and a transparent approach. The purpose is not to approach vendors with suspicion as a default but to ensure that you are procuring the right tools for your objectives.
Table of Contents
OVERALL SOLUTION
1. Is your eSIM IoT solution ready to use today?
This is a question that every vendor will have a different answer for – also depending on what component(s) of the ecosystem they provide. For a vendor that promises the full ecosystem, “ready” means that they have profiles, an eSIM IoT Remote Manager and SGP.32 eUICC SIMs available. However, this doesn’t necessarily mean that you must buy or use all 3 components from this vendor, but it demonstrates that the vendor is ready for the whole ecosystem.
For pure connectivity providers supplying profiles, “ready” means that they can provide profiles that can be downloaded from an eSIM IoT Remote Manager into an SGP.32 eUICC. For a SIM manufacturer, “ready” means that, at the very least, they have form factors that can run SGP.32 functionality on eUICC running in that form factor. For eSIM IoT Remote Manager providers, “ready” means that the product –either with its own UI or via an API– supports all the profile functions.
And of course, bears highlighting again that even when a vendor is SGP.32-ready with any of the applications above, it doesn’t mean that the components in their SGP.32 solution are interoperable or interchangeable, ergo it doesn’t mean they can deliver the promise of avoiding the dreaded vendor lock-in. More on that right away.
2. Are all the components interchangeable?
This is the question that tests the most significant driver: vendor lock-in. That’s why it’s worth asking plainly because vendors may answer with a tricky word: “interoperable.” Interoperable means the components can technically talk to each other. Interchangeable means you can actually swap them in practice. The gap between the two is almost always commercial, not technical, so the goal here is to push past the technical answer to the commercial one: not “can these work together” but “can I replace any single component – SIM, eSIM IoT Remote Manager, or profile – without the other two breaking, and without a penalty.”
Checks: eUICC, eSIM IoT Remote Manager, interoperability with connectivity profiles; commercial lock-in; future-proofing.
Red flag
Any answer that stays on “interoperable” and won’t move to interchangeable. Also: yes-you-can-swap paired with a charge for swapping, a multi-year payment commitment, or the pieces only being interchangeable as long as you stay within their catalog or their partners.
Green flag
Any of the three components can be replaced independently, at any time, with no switching penalty and no requirement to keep buying the other two.
3. Is your solution GSMA-certified? Which components and how?
Certification tells you a product was built and tested against the standard – but “the solution is certified” is a vague claim, because a solution has several components and they’re certified separately, by different bodies. The eUICC is functionally certified through GlobalPlatform. The IoT device itself carries its own certification for the on-device profile assistant (through GCF/PTCRB). The eSIM IoT Remote Manager can be brought under GSMA’s security accreditation. There’s no single stamp that covers the whole thing. On top of that, SGP.32 is tested against its own test specification.
This is where you catch the SGP.22-dressed-as-SGP.32 solutions from the market section: ask which component is certified, against which specification and version, and to see the certificate.
Checks: genuine SGP.32 compliance; per-component certification; correct spec version; SGP.22-in-disguise.
Red flag
A blanket “yes, we’re GSMA-certified” with no component or specification named. Certification that turns out to cover an SGP.22 eUICC running an app that imitates the SGP.32 flow, or a component tested only against the older consumer spec. Anything they can’t produce the actual certificate for.
Green flag
They name the certified component, the specification and version it’s tested against (SGP.32 via SGP.33, v1.2), and the eUICC is certified for SGP.32 itself – not SGP.22 with a workaround on top.
→ Follow up question, if the answer is no: What’s the exact certification date and against which test spec?
4. Is this true SGP.32 remote provisioning, or a proprietary multi-IMSI / SGP.22-with-orchestration solution marketed as SGP.32? What breaks if I try to leave?
Some products get sold as SGP.32 that aren’t: SGP.22 with an orchestration layer bolted on to imitate the flow of bulk remote SIM provisioning as outlined in SGP.43. Less frequently, you may find multi-IMSI sold as remote SIM provisioning, where the SIM swaps between network identities the vendor pre-loads and controls. Multi-IMSIs may be a solution to some of the original eSIM IoT drivers but you can’t download profiles from an outside operator. Both these cases can look similar to SGP.32’s remote SIM provisioning in a demo. “What breaks if I leave?” is what cuts through it: in a true SGP.32 ecosystem, there’s nothing you can’t migrate, because the components are standardized and certified.
Checks: Genuine SGP.32 vs proprietary lookalike; vendor lock-in, technical and commercial; exit cost.
Red flag
“SGP.32-compatible,” “SGP.32-ready,” or “SGP.22 with .32 orchestration on top” — all ways of saying not actually SGP.32. A “what breaks if I leave” answer that reveals the flexibility lives in their system, not on your eUICC.
Green flag
Named, verifiable certificates for the actual components; an outline of the portability process where nothing breaks, because the parts are standardized and yours to move.
PORTABILITY & COMPONENT INTERCHANGEABILITY
5. Do you enforce the eSIM IoT Remote Manager platform, or can we use another one? Can I migrate eSIM IoT Remote Managers without touching the hardware?
This is the lock-in question for the management layer, and the thing to understand is where the lock actually sits. The standard is designed against lock-in: an eSIM IoT Remote Manager can be associated with an eUICC at any point in its life. More than one eSIM IoT Remote Manager can be associated at once, and no hardware needs touching to switch.
But there’s a catch built into how a new eSIM IoT Remote Manager gets added: the invitation has to come from an eSIM IoT Remote Manager already associated with the device. Adding the second eSIM IoT Remote Manager’s configuration data is an operation the standard leaves optional for an eSIM IoT Remote Manager to support. So if the eSIM IoT Remote Manager you start with doesn’t implement it –what is called a “non-configurable” eSIM IoT Remote Manager– it can simply never hand you off to another one, and you’re stuck with it for the life of the fleet.
The SIM chip isn’t locked to anything but the eSIM IoT Remote Manager might be the one not letting it attach to another eSIM IoT Remote Manager. That makes your starting eSIM IoT Remote Manager the highest-stakes choice in the whole solution.
Checks: eSIM IoT Remote Manager vendor lock in commercial. Insurance.
Red flag
They require their own eSIM IoT Remote Manager with no option to add another. This is a non-configurable eSIM IoT Remote Manager that can’t push a new association. “You can migrate” without confirming their eSIM IoT Remote Manager actually implements the add-eSIM IoT Remote Manager operation. Migration that’s technically supported but gated behind a switching fee or multi-year commitment. This is the commercial lock behind the technical yes.
Green flag
You’re free to use another eSIM IoT Remote Manager, their eSIM IoT Remote Manager supports adding and switching associations, and you can move remotely at any time – no hardware touch, no penalty.
6. Are you interoperability-tested with eUICCs, eSIM IoT Remote Managers and SM-DP+ servers from other vendors, or only your own stack?
This question is the ultimate ask for the interoperability proof. A vendor whose components only work together within their own stack has built a walled garden. What you need is evidence they’ve tested against other vendors’ eUICCs, eSIM IoT Remote Managers, and SM-DP+ servers — because that’s the only thing that tells you your parts will still work once you swap one of them out. “It all works within our stack” is not portability.
Checks: interoperability in practice; vendor lock-in, technical.
Red flag
Everything is interoperable “within our stack” or “among these providers” — a closed set presented as openness.
Green flag
Yes — independently, cross-vendor tested with named third-party eUICCs, eSIM IoT Remote Managers, and SM-DP+ servers, with results they’ll show you.
7. What does migration to another connectivity provider look like if our eSIMs are tied to your eSIM IoT Remote Manager?
The profile is downloaded and stored in the SIM card, not the eSIM IoT Remote Manager. The eSIM IoT Remote Manager only orchestrates the initial download. The standard instructs that an eSIM IoT Remote Manager can download any profile. But as we’ve seen a few times now that “theoretically possible” doesn’t necessarily mean “possible in practice”.
A vendor can have its own profile menu in the eSIM IoT Remote Manager and decline to orchestrate a download from an operator it doesn’t sell – the lock is commercial, not technical. And even where nobody blocks you, the profile has to be tested and confirmed on your specific eUICC/eSIM IoT Remote Manager combination, not just possible in principle.
Checks: profile lock-in, technical and commercial
Red flag
The eSIM IoT Remote Manager only downloads profiles the vendor sells or won’t orchestrate a download from profiles they don’t provide. “It’s interoperable” with no confirmation that the profile you want is tested on your eUICC/eSIM IoT Remote Manager. A migration that’s technically allowed but carries a switching charge or a contract that outlasts the fleet’s need for it.
Green flag
The eSIM IoT Remote Manager will orchestrate a download from any SM-DP+ you choose, the profiles you care about are confirmed tested on your eUICC/eSIM IoT Remote Manager combination, and there’s no switching penalty for pointing your fleet at a new provider.
8. Can I download other profiles?
– outside your catalog? (if SIM/eSIM IoT Remote Manager provider)
– besides yours (if connectivity provider)?
This tests whether “bring your own connectivity” is real or just a slogan. The technology doesn’t care who sells the profile. As such, a certified SGP.32 eUICC can download profiles from any operator. So if a vendor will only let you load profiles they resell, that’s a commercial decision.
If you are an OEMs it matters twice over: your customer may arrive with an operator they’re already under contract with, and if you can’t load that profile, you either lose the deal or force them to switch. Confirm you can add an operator the vendor has no commercial stake.
Checks: Profile and eSIM IoT Remote Manager interoperability and interchangeability
Red flag
Any response that names specific providers and leaves it at that. You can only load profiles they resell, or “yes” with no confirmation an outside operator has actually been tested on your setup.
→ Follow up question: Are these commercial partners of yours or just examples? Can I bring any provider?”
Green flag
You can download any profile from any provider you wish.
9. Who holds the eUICC keys needed to re-register devices to a new eSIM IoT Remote Manager, and will you contractually commit, in writing, at signing, to hand them over on exit?
Checks: all-component vendor lock, technical. Term commitment, commercial. Insurance.
Red flag
We retain the keys or that’s handled at a case by case basis
Green flag
You get the keys. Your freedom to leave and take the keys with you is contractually formatted and signed.
SIMs + PRELOADED/BOOTSTRAP PROFILE
10. How many times can the bootstrap profile be reused to download/switch operational profiles? Is it unlimited or “one shot and die”?
Checks: Fallback/insurance
Red flag
It’s a one-time profile.
Green flag
The bootstrap profile is usable for the lifetime of the device
11. Can I load your operational profiles onto SGP.32 eUICCs I’ve already bought from a third party or must I buy SIMs from you?
In SGP.32, there’s no technical reason a profile has to come with the SIM. A profile downloads onto any certified SGP.32 eUICC, whoever made it. So if a provider says you must buy their SIMs to get their profiles, that’s a commercial rule they’ve chosen, not a limit of the technology. The one thing to confirm is that their profile has been tested on the specific eUICC you already own, not just assumed to work.
Checks: logistics simplification; SGP.22-in-disguise; interoperability, technical and commercial.
Red flag
You must buy SIMs from us.
Green flag
Any GSMA-certified SGP.32 eUICC works – you can bring your own SIMs, just as you can bring your own connectivity and your own eSIM IoT Remote Manager.
12. If I use your bootstrap, is there any per-profile-download fee, and does the bootstrap lock me into your connectivity?
The bootstrap has one job: get the device online the first time so it can pull its real profile. But because every device has to go through it, it’s an easy place to quietly attach costs or strings.
Two costs to watch for: First, a fee every time you download a profile. Since downloads are how you switch operators, a per-download charge is really a tax on the flexibility you bought SGP.32 for. Second, a bootstrap that only lets you reach the vendor’s own profiles, so the thing meant to start your fleet also quietly decides who you can connect to. Neither is required by the technology; both are commercial choices worth surfacing before you sign.
Checks: additional or punitive costs; connectivity lock-in.
Red flag
There’s a charge per download, or the bootstrap only routes to their own profiles.
Green flag
No download fee, and the bootstrap gets you online without limiting which operators or profiles you can move to next.
COMMERCIAL TERMS & BILLING MODEL
13. Can you show me a breakdown of every recurring fee across all components? eSIM IoT Remote Manager, profiles (download + operational connectivity), and SGP.32-ready eUICC SIMs in X form factor?
The cost of an eSIM IoT solution is scattered across separate components, which makes it easy to quote a low number on one and carry the margin on the others. A cheap eSIM IoT Remote Manager can sit next to a per-download charge; a good SIM price can hide expensive operational connectivity. The only way to compare vendors honestly is to force every recurring line into the open at once and add them up yourself.
Checks: total cost of ownership; hidden or punitive fees.
Red flag
A single bundled number they won’t itemize, or “it depends” on the components that happen to carry the cost. Any fee that only appears when you ask for the full breakdown.
Green flag
An itemized list of every recurring charge, including eSIM IoT Remote Manager, profile download charges –if in the business model–, operational connectivity –data charges–, and the eUICC in your form factor. That you can total and compare against other vendors.
14. Do you have minimum volume commitments, contract length, and lock-in period?
Every technical freedom in this guide can be undone by a contract. A solution can be fully interoperable, fully certified, and genuinely portable — and still trap you if leaving means breaking a multi-year commitment or missing a volume minimum you no longer hit. This is where the commercial lock that shadows the technical one gets written down, so read it as carefully as any spec sheet.
Checks: commercial lock-in; exit cost; flexibility to scale down.
Red flag
High minimums and multi-year lock-in just to access the eSIM IoT Remote Manager; volume commitments that penalize you if the fleet grows slower than planned.
Green flag
Low or no commitment, usage-based pricing, and a short exit notice.
15. Is eSIM IoT Remote Manager access still available and at what price after I leave for another connectivity provider?
A vendor can offer a free or cheap eSIM IoT Remote Manager while you’re a connectivity customer, so the management layer looks like a non-issue, until you switch providers and the eSIM IoT Remote Manager price you never really negotiated suddenly activates. So price the eSIM IoT Remote Manager as a standalone product now, on the assumption you will leave, and get that price in the contract.
Checks: commercial lock-in; exit cost; eSIM IoT Remote Manager independence.
Red flag
The eSIM IoT Remote Manager is free only while you’re also a connectivity customer, or the per-SIM eSIM IoT Remote Manager fee activates the moment you change eSIM IoT Remote Manager or connectivity provider. A time commitment on the eSIM IoT Remote Manager that outlasts your reason to keep it.
Green flag
A defined, reasonable eSIM IoT Remote Manager price that holds even after you leave connectivity – a rolling per-year cost, written into the contract, that doesn’t punish you for switching connectivity.
PROFILES & CONNECTIVITY
16. What’s the lead time to integrate a new profile/operator?
A vendor can say any operator works, but the lead time to actually get a new one running tells you whether that’s proven or theoretical. If they’ve done it before, its days; if every new operator is a fresh integration and testing effort, the answer is weeks or months. Ask for a specific timeline and who does the work, because that number is the real measure of how portable your connectivity is.
Checks: Checks: interoperability in practice; hidden switching cost; time-to-market.
Red flag
No firm timeline, “we have a catalog of profiles to choose from”or “it depends” with every operator treated as a custom project. A lead time long enough to stall a committed launch.
Green flag
“Any profile from any operator can be downloaded with activation codes. The lead time is X”. A defined onboarding process and a short, specific lead time – evidence they’ve integrated outside operators before, not just in principle.
17. Is profile provisioning fully data-driven and API-driven with no SMS and no QR/human step?
This is a quiet tell for whether you’re looking at real SGP.32 or SGP.22 wearing its clothes. SGP.22 was built for consumer phones, where a person scans a QR code or taps a screen to switch profiles. That doesn’t scale to a fleet of thousands of headless devices, and it’s exactly what SGP.32 was designed to remove. So if the process still needs a QR scan, an SMS, or a human clicking through a portal, that’s a strong sign the “SGP.32” solution is really an older consumer flow dressed up. Ask whether you can do everything through an API with no manual step even if you don’t need API, because that’s what lets you provision at scale and automate it into your own systems.
Checks: future-proofing; SGP.22-in-disguise; automation at scale.
Red flag
It has to go through our portal, or any step needs a QR scan, SMS, or human action.
Green flag
Full API access with activation codes provided — no SMS, no QR code, no human step in the loop.
IPAe/IPAd
18. Does choosing IPAe vs IPAd change my ability to switch eSIM IoT Remote Manager or profiles later?
IPAe vs IPAd is really an effort-vs-control tradeoff. The one difference that matters is that, with IPAe, that logic is pre-loaded by the SIM vendor. This means that if the eUICC ships pre-paired to one eSIM IoT Remote Manager, you have fewer levers to undo it yourself; with IPAd, you control the connection logic. So IPAe doesn’t lock you in on its own but it potentially gives you less room to escape a lock already built into the SIM. Either way, the real question is whether the eUICC is configurable.
Checks: vendor lock-in, technical; where control actually sits.
Red flag
A vendor who frames IPAe as “simpler” without confirming the eUICC is configurable.
Green flag
Either option works, switching depends on a configurable eUICC, not the IPA type. With IPAe, they confirm the eUICC isn’t pre-locked to their eSIM IoT Remote Manager.
19. Is there any technical, contractual, or commercial penalty that triggers when we point devices at a different eSIM IoT Remote Manager?
This is the catch-all that closes the gaps the other questions leave open. A vendor can answer every earlier question cleanly –yes it’s interoperable, yes you can migrate, yes you can self-host– and still make leaving expensive through a fee, an early-termination charge, a minimum-term commitment, or a per-device “migration cost.”
Technical freedom and commercial freedom are separate, and this question forces the commercial one into the open. Ask it as a flat yes/no. Then make sure that you get a complete breakdown of the charges. The goal is to surface the price of leaving before you sign, not discover it when you try.
Checks: eSIM IoT Remote Manager interoperability, technical and commercial.
Red flag
Any penalty, fee, or committed term that triggers on migration – especially one that only surfaces when you ask directly. Vague answers like “it depends on your contract.”
Green flag
No technical, contractual, or commercial penalty for pointing devices at another eSIM IoT Remote Manager leaving costs nothing beyond what you’ve already used.
