Kigen and SGP.32: The Lock Burned Into Silicon

The short version: Kigen sits on the deepest lock-in point in the whole SGP.32 architecture – and is the vendor working hardest to prove it isn’t one. The eUICC operating system is burned into the chip at manufacture and cannot be changed once a device ships. That makes the OS a more permanent lock than the operator profile SGP.32 was designed to free. Kigen owns that layer for a large share of the market, yet it is also the player pushing hardest on interoperability, multi-vendor testing and the standard itself. Understand Kigen and you understand the difference between a lock that gets exploited and a lock that gets held responsibly.

Who Kigen actually is

Kigen is a Hampshire-based eSIM and iSIM security specialist, spun out of Arm and backed by Arm, SoftBank Vision Fund 2 and SBI Group. Where a connectivity player like Eseye sells you a managed service, Kigen sells the thing underneath everyone’s service: the operating system that runs on the secure element inside the device, plus the certified silicon it runs on. Its GSMA-certified eUICC ships in several form factors, from the solderable MFF2 down to the 2mm x 2mm MFF4 for space-constrained designs, and as plastic SIMs with remote-provisioning functionality built in.

On top of the OS sit two more products. The Kigen eIM (the eSIM IoT Remote Manager defined by SGP.32) handles remote profile management, and Kigen Pulse is the orchestration console that ties fleets together across managed, AWS-hosted or self-managed deployments. The CEO is Vincent Korstanje, and his framing of SGP.32 is bullish: he calls it a defining milestone that removes the complexity that has held back enterprise IoT scale.

What Kigen brings to SGP.32

Kigen is unusual because it has a hand in almost every layer of the SGP.32 stack at once. It makes the certified eUICC hardware. It writes the eSIM OS that runs on it. It operates an eIM, delivered as a managed service through its GSMA-accredited data centres, on AWS, or self-hosted on a customer’s own infrastructure. And it helps write the specification: its head of standards chairs one of the GSMA eSIM working groups, which means Kigen is shaping the rules it also builds to.

The commercial momentum in 2026 has been real rather than slideware. In April it announced a joint SGP.32 connectivity portfolio with KORE, with commercial availability planned later in the year. In early July it went further in the direction that matters most for this profile, partnering with Denmark’s Onomondo on a pre-loaded, interoperable SGP.32 offering, with Onomondo’s connectivity profiles loaded onto Kigen’s certified eSIMs during manufacturing so devices ship already connected. There is a named enterprise deployment too: US utility Evergy uses Kigen’s eSIM OS and eIM for automated failover between private LTE and public networks, managed through Kigen Pulse.

The story behind the facts

Here is what makes Kigen the most interesting company in the UK landscape to write about honestly. Almost every SGP.32 vendor claims to end lock-in in their marketing. Kigen is one of the few actually building the evidence for it.

Consider the pattern. The Onomondo partnership is framed explicitly around avoiding long-term dependence on a single network provider. Kigen ran a public “Reality Check” that migrated live devices between three different connectivity providers – Onomondo, Soracom and ZARIOT – on a single set of its eSIMs, deliberately not a single-vendor demo. Its eIM is tested against 60+ IoT modules and a broad partner cohort spanning connectivity players and operators including AT&T Business and Vodafone. And it took part in what was billed as the first independent public test of SGP.32 interoperability, switching live devices between providers on its SAS-certified eIM.

None of that is charity. Kigen’s commercial interest is in SGP.32 becoming the trusted default, and the fastest route there is to remove buyers’ fear of being trapped. But the effect is genuine: if you are going to be locked into anyone’s OS, being locked into the one that publicly proves its profiles and providers are swappable is a materially better position than the alternative. The openness is strategy, and it also happens to be the right thing for the buyer.

Where the lock-in actually lives

This is why the eUICC OS is the sharpest example of conservation of lock-in. SGP.32 makes the operator profile portable, and the orchestration layer above it is at least migratable with effort. The OS is neither. It is chosen before the product is built, written into the secure element, and cannot be swapped in the field – there is no over-the-air path to a different eUICC OS on a device already in the ground. Whatever else moves, this decision is permanent from the moment the board is manufactured.

That permanence is exactly why Kigen’s openness matters more than a connectivity vendor’s would. A managed-service lock can be escaped, painfully, by re-platforming. An OS lock cannot be escaped at all without replacing hardware. So the only meaningful mitigation is trust: evidence that the OS you commit to will keep letting you switch everything above it – profiles, providers, orchestration – for years. Kigen has understood that the way to win the permanent layer is to make the permanence feel safe. It is the deepest lock in the stack, held by the player doing the most to prove it is survivable.

If you are evaluating Kigen

The applied questions for the OS layer are different from the ones you ask a connectivity vendor, because the stakes are set at design time and cannot be revisited:

• This is a hardware-era decision. Choosing an eUICC OS is a board-design commitment, not a contract you renegotiate. Treat it with the seriousness of a component you can never second-source. See what to ask your hardware provider.
• Demand the interoperability evidence. Kigen’s advantage is that it can show you public, multi-vendor proof of profile and provider switching. Ask for it by name – the Reality Check, the independent interoperability test – and make any OS vendor match that bar.
• IPA-e or IPA-d. Where the profile assistant runs affects who controls provisioning and how constrained your device can be. Pin this down early – see IPA-e vs IPA-d.
• Deployment model for the eIM. Managed, AWS-hosted or self-managed each carries a different dependency profile. Decide how much of the control plane you want to hold yourself before you commit.

Where Kigen sits in the landscape

If Eseye holds the control plane, Kigen holds the silicon – and between them they own the two ends of the SGP.32 stack that matter most for lock-in. The eUICC OS is the deepest and most permanent of the four places the lock relocates to, which makes Kigen’s answer to the “where is the stickiness” question the most structurally important of any UK player. That it is also the player working hardest to keep everything above that layer open is the whole point: the lock is real, permanent and unavoidable, and the right response as a buyer is not to pretend it isn’t there but to pick the vendor most committed to proving it is safe to live with.

By Peter Green