Kigen has spent this week putting its connectivity partners in the shop window, and Soracom got the spotlight. The post carries one line from Soracom’s CTO that I think every IoT buyer should read twice: SGP.32 is rapidly becoming a requirement in automotive and enterprise IoT RFPs. I agree with him. But the SGP.32 RFP story is older than this post, and the half of his sentence that matters most is the half nobody is talking about.
The SGP.32 RFP story at a glance
- What happened: Kigen published a LinkedIn partner spotlight on Soracom, one of the activation-ready connectivity partners in the Kigen IoT eSIM Starter Kit. Soracom replied that SGP.32 is moving off the roadmap and into the RFP.
- The claim: SGP.32 support is turning into a procurement requirement in automotive and enterprise IoT tenders.
- The caveat: early adopters activate first, but only once their target networks switch on SGP.32 support.
- The ecosystem: 13 connectivity partners at the kit’s July launch, which Kigen now describes as 13+, with more operators finishing their activation workflows.
- Why it matters: if SGP.32 is in your RFP, you need to know what to ask for, because “SGP.32 ready” now means very different things depending on who says it.
The news: Kigen puts Soracom in the shop window
The post itself is straightforward. Kigen is promoting its partner ecosystem around the Starter Kit it launched in July: ten certified eSIMs, three months on Kigen’s eIM and Pulse platform, device-side tools including the C-SDK and IPAd, and profiles from participating operators and MVNOs that have tested activation on Kigen’s eSIMs. I covered the launch in our July round-up, and the kit is unpacked at the eUICC level on euicc.co.uk.
The launch cohort was 1oT, floLIVE, Hologram, iBASIS, KDDI America, KORE, NuvoLinQ, Onomondo, Pangea Connected, Semtech, Skylo Technologies, Soracom and ZARIOT. Kigen also says the kit works with hundreds of other operator profiles already tested for download, sourced separately, and that more MNOs and MVNOs are finalising their workflows.
Soracom is a natural pick for the spotlight. It moved its SGP.32 eSIMs and its Connectivity Hypervisor orchestration to commercial availability in July, and it was one of the providers used in the independent IoT Stars test in April, where live devices were migrated between connectivity providers over the air using Kigen’s eIM.
The quote is older than the post, and that is the interesting part
I went back through the record, because a claim like this is only as good as its track. What I found is a claim that has been widening, not one that has just appeared.
| When | Where | What Soracom said |
|---|---|---|
| July 2025 | Connectivity Hypervisor announcement | SGP.32 becoming a requirement in automotive RFPs, with live testing on eUICC, eIM and SM-DP+ infrastructure |
| March 2026 | MWC pre-order launch | Widened to automotive and enterprise IoT RFPs; infrastructure built ahead of demand |
| July 2026 | Kigen Starter Kit launch, Soracom general availability | Same statement used as Soracom’s partner quote; SGP.32 eSIMs go on sale |
| November 2026 | Kigen LinkedIn spotlight | Quote recirculated; Soracom adds that SGP.32 has moved off the roadmap and into the RFP |
So what is genuinely new this week is not the quote. It is that the language has shifted from “coming” to “here”. Sixteen months ago this was an automotive story. By spring it was enterprise as well. Now the vendors are talking about it as something buyers are already writing into tenders, not something they will be writing in next year. That matches what I am seeing: SGP.32 has stopped being a nice-to-have line in a requirements spreadsheet and started being a gate.
The half of the sentence nobody is reading
Here is the bit I would underline. Yasukawa’s own framing is that customers who commit early will be first to activate once their target networks switch on SGP.32 support. That is an honest sentence, and it tells you exactly where the bottleneck sits.
It is not the eUICC. Certified eSIMs are shipping. It is not the eIM. Kigen’s is SAS-certified, and others are live. It is the operator side. Soracom’s own general availability release said as much: the capability is fully built, but wider availability to end customers depends on partner operators completing their profile integrations. Kigen’s “more partners preparing to join” says the same thing in friendlier words.
In my view, that is the gap a lot of RFPs are about to fall into. A tender that asks “do you support SGP.32?” will get a yes from almost everyone. The question that actually separates suppliers is: which profiles, from which operators, in which countries, can I activate on this hardware today, and which ones are still roadmap?
Why automotive is pulling first
It makes sense that automotive led this. A connected car or a two-wheeler is in service for well over a decade, and the network it ships on is a bet that coverage, pricing and operator roadmaps will stay still for that long. They will not. SGP.32 turns that bet into a decision you can revisit.
The supply side is moving to meet it. In September Kigen announced the first GSMA eSA-certified automotive eSIM supporting SGP.32 v1.3, built on Infineon’s TEGRION SLI22 controller, with emergency profile handling and digital activation codes among the v1.3 features it highlights, and OEM sampling in MFF2 from October. That is worth reading precisely: it is the first eSA-certified automotive eSIM on v1.3, not the first SGP.32 product. It also updates something I wrote in our v1.3 explainer: certification work against v1.3 has now started to land, even if v1.2 is still where most of the market designs today.
Writing an SGP.32 RFP clause properly
“Must support SGP.32” is a weak clause. It is too easy to answer yes to. If I were drafting the requirement today, this is what I would ask for instead:
- Certified eUICC, by version. Is the eSIM eSA-certified, against which SGP.32 version, and who supplies the eUICC OS? Remember the OS is fixed at manufacture, which is the lock I explored in our Kigen profile.
- The eIM, and whether you can leave it. Is the eIM SAS-certified, who operates it, and can the eSIMs be re-pointed to a different eIM later? That is the eIM portability question. An orchestration layer like Soracom’s Connectivity Hypervisor or Onomondo’s eIM is useful, but it is still a control plane you are choosing. See how Onomondo approaches it.
- Activation-ready today, named. Ask for a list of operator profiles that are tested and activatable on the proposed hardware now, by country, separated from those that are “in progress”.
- The bootstrap profile. Which profile does the device ship on, who owns it, and what happens to it after you switch? The bootstrap issues catch people out, so it pays to choose the bootstrap provider deliberately.
- The device side. Is the module and firmware genuinely SGP.32-ready, and is it IPAd or IPAe? “eSIM-capable” is not the same thing, as I covered in SGP.32 modem compatibility and IPAe vs IPAd.
- A bench test before award. Starter kits from Kigen and others exist precisely so you can break this on the bench before you break it in the field. Make a short evaluation part of the tender.
For the wider checklist, what to ask your eSIM provider goes deeper.
My take
I think Soracom is right, and I think Kigen is right to keep pushing the ecosystem story, because the ecosystem is now the product. The standard is done, certified silicon and eIMs are shipping, and buyers have started asking for it by name.
But “SGP.32 is in the RFP” is the start of the hard part, not the end of it. The suppliers who win those tenders will be the ones who can show named, activatable profiles on the networks the customer actually needs, not the ones with the best roadmap slide. And buyers should remember that SGP.32 does not remove dependence; it moves it somewhere else. Write the RFP so you can see where it has moved to.
I will keep tracking which operators actually light up in the Kigen ecosystem and elsewhere over the coming months. That list, not the press releases, is the real measure of how ready SGP.32 is.