July 23, 2026 · eSIM, IoT eSIM, Kigen, SGP.32

eUICC on the bench: what Kigen’s SGP.32 Starter Kit really tests

Every few months the eSIM industry produces an announcement that looks like a product but reads, if you tilt it to the light, like a status report on a standard. Kigen’s new IoT eSIM Starter Kit, recently reported on IoT Portal, is one of those. Strip away the kit framing and what remains is a fairly candid statement about where SGP.32, and the eUICC architecture underneath it, has actually reached.

Here is the eUICC-level read, from a site that does not sell any of this.

The stack the kit is really exercising

When people say “SGP.32” they usually mean the specification. What actually has to work is a stack. An eUICC, the tamper-resistant secure element that stores the operator profiles. An eIM, the eSIM IoT Manager that orchestrates profile operations remotely. An IPA, the IoT Profile Assistant that carries out those operations on the device itself. One or more SM-DP+ servers that hold and deliver the profiles. And the network that the chosen profile finally attaches to.

SGP.32 exists because the earlier eUICC models did not fit IoT. The consumer specification assumes a user, a screen and a local profile assistant a person can prod. The older M2M model leaned on an SM-SR and operator-led control that enterprises found rigid. SGP.32 adds the eIM and the IPA so that constrained, headless, remotely deployed devices can have their profiles managed without a human in the loop and without surrendering control to a single operator. That is the whole point, and it is also the part that has been slow to arrive in a form you can actually buy and test.

What is in the kit, mapped to the architecture

Kigen’s kit is, in effect, a boxed version of that stack. Mapped to the eUICC architecture rather than the marketing, it contains:

10 eSA-certified Kigen eSIMs – the eUICC hardware, carrying the certification that says the secure element itself has been independently assessed.
Three months of SAS-certified Kigen eIM and Kigen Pulse – the orchestration layer, plus Kigen’s management and visibility platform on top.
Kigen C-SDK and IPAd – the device-side integration, including the IoT Profile Assistant that lives in the device (the “d” in IPAd) rather than inside the eUICC.
Activation-ready profiles from 13 connectivity partners – 1oT, floLIVE, Hologram, iBASIS, KDDI America, KORE, NuvoLinQ, Onomondo, Pangea Connected, Semtech, Skylo Technologies, Soracom and Zariot – pre-cleared so teams test the mechanism instead of chasing onboarding paperwork.

The reason for assembling it this way is that eUICC projects rarely fail on any single component. They fail on the seams between them: the profile that downloads but will not enable, the exception the eIM does not handle gracefully, the device that behaves impeccably on the bench and sulks the moment the network it was provisioned for drops away. A single environment where all five layers are present and certified is less exciting than a demo and considerably more useful.

The certification layer nobody reads but everybody relies on

Two acronyms in the announcement do more work than they let on. eSA is the eUICC security assurance scheme, the independent evidence that the secure element holding your profiles has been evaluated rather than merely asserted to be secure. SAS is the GSMA’s Security Accreditation Scheme, which in this context means the eIM and its subscription-management operations have been accredited to the same discipline the industry already demands of profile production.

For an enterprise deploying devices that will sit in the field for a decade, these are not box-ticking exercises. They are the difference between a connectivity foundation you can defend in a security review and one you cannot. It is worth saying plainly that certification of the components does not certify your integration of them, which is precisely why a testable kit exists.

The real promise, and the honest caveat

The multi-operator angle is the part that matters for the eUICC’s original pitch: a single secure element that can hold and switch between operator profiles across a device’s life. Kigen makes a point of not prescribing a provider. The kit is built around bringing your own operator and widening the options later, with hundreds of additional profiles already tested for download and available separately. That is the eUICC promise finally behaving roughly as advertised, rather than as a slide.

The honest caveat, which a vendor-neutral site should state out loud: a starter kit proves the mechanism, not the economics. Profile portability is as much a commercial question as a technical one, and the friction that ends most “just switch operators” ambitions is contractual, not cryptographic. SGP.32 removes the technical excuse for lock-in. It does not remove the commercial incentive to create it. Watch how the profile terms read, not just how the download flows.

What this actually tells us

Read at the eUICC level, Kigen’s kit is a signal that the SGP.32 stack has moved from specification to something you can put on a bench and break on purpose before you break it in the field. The company is leaning on more than 18 months of eIM trials and over 100 customer journeys, with the likes of Digi International, Evergy, Itron and Robustel already attached to its SGP.32 work. That is evidence, not proof, but it is more than most eUICC announcements offer.

The specification was always the easy part. The stack around it is where eUICC either delivers on its decade-old promise or quietly does not. On this evidence, it is starting to.

For the full breakdown of the kit and the complete partner list, read the report on IoT Portal. For the standards background, see our explainer on what SGP.32 is, and the companion summary on our sister site sgp32.co.uk (SGP.32 gets a proving ground).