Get Early Access

The Kigen eSIM IoT Manager and SGP.32: A Complete Guide to the First Certified eIM

 

EIM – The component at the heart of SGP.32

Every meaningful conversation about SGP.32 eventually arrives at the same three letters: eIM. The eSIM IoT Manager, or eIM, is the piece of the architecture that turns a good specification into an operational reality. It is the control plane for an entire fleet of IoT eSIMs, the thing that lets an operations team download, switch and retire mobile network profiles across thousands of devices without a single site visit.

There is a generic version of this story, which we have told elsewhere on this site. This page is about the specific one: the Kigen eSIM IoT Manager, the first eIM certified as GSMA-compliant, and the one a large slice of the cellular IoT industry has quietly standardised on. If you want to understand not just what an eIM is but what the leading production eIM actually looks like, this is the page for it.

We will cover what the Kigen eIM is, where it sits in the SGP.32 stack, what it actually does day to day, how it is deployed, who is running it in the field, and, importantly, how it stacks up against the other eIM and orchestration options now reaching the market. The last part matters. An honest guide to the leading eIM has to be honest about the alternatives.

A quick recap: what an eSIM IoT Manager (eIM) is

For anyone arriving here cold, the short definition. An eSIM IoT Manager (eIM) is the server-side management component introduced by the GSMA SGP.32 specification. Its job is to remotely manage the eUICCs (the eSIM chips) across a fleet of IoT devices, instructing them to download a profile, enable it, disable it, switch to another, or delete it. GSMA’s formal term for it is the eSIM IoT remote Manager; some vendors also write it as the eUICC IoT Manager. The acronym eIM is universal.

The eIM does not act alone. In the SGP.32 architecture it works with three other elements:

The eIM sits above the operator infrastructure and below the enterprise application layer, which is exactly why it is so powerful. It is the single point from which an organisation manages its whole SIM estate. For the full architecture breakdown, including the CoAP transport model and the interfaces between all four components, the deep technical reference lives over at sgp32.co.uk. This page assumes you have the basics and focuses on Kigen’s implementation of that eIM role.

Why the Kigen eIM matters: first, and certified

Being early is not usually a technical virtue. In the eIM market, it is, because the barrier to entry is not code, it is certification, and certification takes time nobody can shortcut.

Kigen announced its eIM in October 2024 and positioned it as the first market-ready eIM fully compliant with the then-current GSMA SGP.32 v1.2 specification. It was the first eIM certified as GSMA-compliant, full stop, and Kigen also operated the first GSMA SAS-SM certified site running an eIM. SAS-SM, the Security Accreditation Scheme for Subscription Management, is the accreditation that lets a site handle the sensitive business of profile provisioning at all. Turning up with it already in hand, rather than “coming soon”, is what separates a product you can put into a fifteen-year utility rollout from one you can only demo.

That first-mover position is not a marketing accident. It flows directly from where Kigen came from. The company was founded out of Arm, is backed by SoftBank Vision Fund 2 and SBI Group, and positions itself among the top five SIM vendors globally, with SAS-UP certified production sites in Dublin and Noida behind the eIM. When the standard needed a reference implementation, Kigen was the company most able to build it, because in a sense it had already been building the pieces for years. For the wider story of the company, its people and its central role in the standard, IoTUK has published a full profile of Kigen and the SGP.32 revolution; this page focuses specifically on the eIM.

Inside the Kigen eSIM IoT Manager

The Kigen eIM is not a single product so much as a small stack of them, designed to be adopted together or piece by piece. Here is what you actually get.

Kigen eSIM OS. Underneath everything is Kigen’s secure eSIM operating system, described by the company as the industry’s most compact secure SIM OS. It runs on removable SIMs, on soldered MFF2 chips, or integrated as an iSIM, and it is tuned for the low-power LPWAN networks (NB-IoT and LTE-M) that dominate massive IoT. The eIM manages eUICCs running this OS, and the OS carries additional capabilities such as in-factory profile provisioning and intelligent profile-switching logic to keep a device connected.

Kigen Pulse. This is the console, the human-facing face of the eIM. Pulse gives administrators a single pane of glass over the fleet: real-time device and profile visibility, and the ability to download, enable, switch and audit profiles from one place. If the eIM is the engine, Pulse is the dashboard, and it is what turns “the standard supports this operation” into “someone on the ops team did it before lunch”.

Kigen APIs. For teams who want eIM capability inside their own connectivity management platform, ERP or device-management stack rather than a separate console, Kigen exposes developer-ready APIs covering the full profile lifecycle. This is how a connectivity provider or a large OEM embeds SGP.32 operations directly into the systems they already run.

The device SDK and IPA enablement. Kigen ships an embedded-C device SDK so that the IPA can be integrated into device firmware cleanly, along with the developer enablement tooling that hardware makers need to bring their kit into the SGP.32 world. This is the often-overlooked half of an eIM story: the server is only useful if the devices can talk to it, and Kigen supplies both ends.

Flexible deployment. The Kigen eIM can be consumed three ways: as a fully managed service inside Kigen’s GSMA-accredited SAS-SM data centres, hosted on Amazon Web Services, or self-managed on the customer’s own infrastructure. All three run under Kigen Pulse for a consistent experience, with support for geo-redundant and hybrid-cloud deployments. For UK and European buyers with data-residency or sovereignty requirements, that self-managed and hybrid option is frequently the deciding factor.

What the Kigen eIM does day to day

Strip away the components and the eIM earns its keep through a small set of operations that used to be impossible without physical access.

It downloads a profile onto a device’s eUICC over the air. It enables that profile so the device connects. It disables it, switches to a different operator profile, or deletes one no longer needed. It does all of this remotely, at fleet scale, on devices that may have no screen, no user, and only intermittent power. And it keeps an auditable record of every operation, which is exactly what a regulated deployment or a security review will ask for.

The practical outcomes are the reason enterprises care. A device can be manufactured once, shipped anywhere, and have its connectivity assigned or reassigned after it is already in the ground. A permanent-roaming block in a foreign market becomes a profile download rather than an engineer with a van. A network that degrades or a carrier contract that ends becomes a switch operation rather than a fleet recall. The eIM is the mechanism that makes connectivity a software decision instead of a logistics problem.

The Kigen eIM in the real world

An eIM is only as credible as its deployments, and this is where Kigen’s ecosystem strategy shows its value. Rather than compete with the connectivity industry, Kigen has made itself the neutral engine beneath it, and the roster of names building on the Kigen eIM has grown quickly.

KORE aligned an SGP.32 connectivity portfolio around Kigen’s certified eSIM and eIM technology, pairing MVNO scale with Kigen’s neutral provisioning infrastructure. Nordic Semiconductor built SGP.32 IoT capability into its nRF9151 System-in-Package and Thingy:91 X prototyping platform using Kigen’s eIM and eSIM OS. floLIVE announced operational SGP.32 support with Kigen, using the eIM and secure eSIM OS to deliver a factory-to-field experience. TEAL preloaded its cloud platforms alongside a Kigen SGP.32-ready OS. 1NCE and Onomondo sit in the same orbit of connectivity partners.

The deployment worth singling out is Robustel, because it shows the eIM reaching real industrial hardware. In late 2025 Robustel adopted Kigen’s eSIM OS, eIM and developer enablement tools across its 4G and 5G router and edge gateway portfolio, extending its existing Smart Roaming capability to orchestrate eSIM profiles with zero-touch provisioning. The elegant part was the retrofit: a plastic Kigen eSIM dropped into Robustel’s existing single and dual-SIM routers with no change to the bill of materials. We covered the technical detail of that partnership in full over at euicc.co.uk, and it is the clearest template yet for how established hardware makers will bring the eIM into products already in the field.

The Kigen eIM versus the wider field

No honest guide to a leading product pretends it is the only one. The eIM market is real and getting more competitive, and the right eIM for a given deployment depends on the connectivity strategy around it. Here is the landscape as it stands.

Among the established secure-element vendors, Thales is the most visible alternative, with a large eSIM management business, SGP.32 profile-download workflows, its own IPAe implementation and Cinterion modules, and orchestration deployments such as the recent multi-operator SGP.32 network built with Bridge Alliance operators in Asia-Pacific. IDEMIA brings a GSMA-certified SGP.32 eSIM ecosystem and has appeared in orchestration partnerships alongside Cisco’s IoT Control Center and Tele2 IoT. Giesecke+Devrient (G+D), another long-standing SIM technology provider, is building eIM capability into its connectivity portfolio.

Beyond the incumbents, the field is broadening. Simplex Wireless has a certified eIM platform. TEAL has taken a deliberately open route with OpenEIM, positioning it as a free and open eIM to counter the risk of eIM lock-in, where a reseller’s eIM only ever enables that reseller’s network. And a layer of orchestration players such as Eseye and Cisco sit above the eIM, offering vendor-agnostic platforms that can front certified components from Thales, IDEMIA and Kigen alike.

So how should you weigh Kigen against that field? A few honest criteria:

The reasonable conclusion is not that Kigen wins every deployment. It is that Kigen is the reference point everyone else is measured against, which for the first mover in a certification-gated market is precisely the position you want to hold. If your next question is which connectivity and SIM strategy to wrap around the eIM, that is a decision we pull apart in more detail at simwise.co.uk.

Standards pedigree: Kigen helped write the eIM

There is one more reason the Kigen eIM carries the authority it does, and it is not a product feature. The eIM as an architectural concept was defined inside the GSMA eSIM Working Group 2, and that working group is chaired by Dr Saïd Gharout, who is also Kigen’s Head of Standards. Kigen did not merely implement the eIM quickly; it was in the room helping to specify what an eIM should be, then went and built the first one against the specification it had helped shape. In a standards-driven market, authoring the rules and shipping the reference implementation is about as strong a position as a company can occupy.

UK and market outlook

For UK organisations the eIM story is moving from theory to procurement. The four UK mobile network operators, EE, Vodafone, Three and O2, are all working on SGP.32-native commercial offerings at various stages, and specialist providers are building their own eIM and SM-DP+ capabilities alongside them. Internationally, Telenor IoT has been among the most advanced with production-ready SGP.32 delivery, and Tele2 IoT has paired SGP.32 bootstrap connectivity with a hardware partnership, evidence that the standard is now shipping rather than merely certified.

The analyst view lines up with the vendor activity. ABI Research expects SGP.32 adoption to accelerate sharply from 2026 onward, driven by asset tracking, smart metering and the migration of existing SGP.02 estates. As that adoption curve steepens, the eIM stops being a specialist term and becomes routine infrastructure, and the eIM that arrived first, certified and neutral, is well placed to underpin a large share of it.

Frequently asked questions

What is the Kigen eSIM IoT Manager? It is Kigen’s implementation of the SGP.32 eIM, the server-side platform that remotely manages eSIM profiles across a fleet of IoT devices. Announced in October 2024, it was the first eIM certified as GSMA-compliant, and it is delivered with the Kigen Pulse console, developer APIs and a device SDK.

Is the eIM the same thing as SGP.32? No. SGP.32 is the GSMA specification. The eIM is the specific management component that specification introduces. The eIM works alongside the IPA on the device, the operator’s SM-DP+, and the eUICC to deliver remote SIM provisioning for IoT.

Can I self-host the Kigen eIM? Yes. The Kigen eIM can be run as a fully managed service in Kigen’s accredited data centres, hosted on AWS, or self-managed on your own infrastructure, all under Kigen Pulse, with geo-redundant and hybrid-cloud options.

Who else makes an eIM? Thales, IDEMIA, Giesecke+Devrient, Simplex Wireless and TEAL (with its open OpenEIM) all offer or are building eIM capability, and orchestration providers such as Eseye and Cisco sit above certified components from multiple vendors. Kigen was first to a GSMA-compliant eIM and first to a SAS-SM certified eIM site.

Does the Kigen eIM lock me into one network? No. Kigen sells no connectivity and operates no network, so its eIM is network-neutral by design. This is a key distinction from eIMs marketed by operators or resellers, which can restrict a device to that provider’s network.

How does the eIM handle low-power NB-IoT and LTE-M devices? The Kigen eIM and eSIM OS are built for exactly these constrained, intermittently connected devices, using the SGP.32 architecture and a lightweight on-device IPA rather than the rich Local Profile Assistant that consumer eSIM assumes.

The bottom line

The eIM is the single most important component SGP.32 introduced, and the Kigen eSIM IoT Manager is the most established example of it in production. First to certification, neutral by design, backed by serious pedigree, and already running under the connectivity portfolios of KORE, Nordic, floLIVE, Robustel and others, it has become the reference eIM the rest of the market is measured against.

That does not make it the automatic answer for every project. The eIM you choose should follow the connectivity, data-residency and lifecycle strategy of your specific deployment, and the field now includes credible alternatives. But if you are trying to understand what a mature, certified, deployed eIM looks like, you start with this one. The eIM is no longer a diagram in a specification. It is live infrastructure, and it is already managing fleets in the field.

For the full SGP.32 architecture and component-by-component technical reference, see sgp32.co.uk. For the complete Kigen company profile and its role in the SGP.32 revolution, see IoTUK. For eUICC and eSIM standards explainers, including the Robustel and Kigen deployment, see euicc.co.uk. For help choosing the right IoT SIM and connectivity strategy, see simwise.co.uk.

 

SGP.32 and the eSIM IoT Manager: How the New Standard Changes IoT SIM Management

SGP.32 is the GSMA’s IoT-native eSIM specification – and the eSIM IoT Manager (eIM) is the component at its heart. This post explains what the eIM does, why it matters, how it differs from the management architectures that came before it, and what it means in practice for organisations managing IoT SIM deployments at scale.

For the complete technical background on SGP.32 – including the full comparison with SGP.02 and SGP.22, the CoAP transport architecture, and a sector-by-sector breakdown of where the standard changes things – read the SGP.32 eSIM and IoT SIM Cards guide at IoTSIMs.co.uk. This post focuses on the eIM specifically: what it is, what it replaces, and why it is the component that makes SGP.32 operationally meaningful for IoT fleet managers.

What is the eSIM IoT Manager?

The eSIM IoT Manager (eIM) is the server-side management platform introduced in GSMA SGP.32. It is responsible for orchestrating eSIM profile lifecycle across an IoT device fleet – pushing provisioning commands to devices, managing profile activation and deletion, and coordinating with mobile operators’ SM-DP+ servers to prepare and deliver profiles to the right devices at the right time.

If you are familiar with SGP.02, the eIM replaces the SM-SR (Subscription Manager Secure Routing). If you are familiar with SGP.22, the eIM replaces the functionality of the SM-DP+ routing layer and the LPA interactions that required user intervention. In both cases, the eIM represents a significant architectural improvement – and removes the most significant operational constraints that made previous eSIM standards impractical for large-scale IoT deployments.

The core capabilities of the eIM are:

What the eIM Replaces: SM-SR and Why It Mattered

Under SGP.02 – the M2M eSIM standard that preceded SGP.32 – the SM-SR sat between the operator’s profile preparation infrastructure and the eUICC in the device. Every profile operation went through the SM-SR, and the SM-SR was typically operated by or tightly coupled to a specific operator or connectivity platform.

This created three problems that limited SGP.02 adoption outside automotive.

First, operator lock-in. Changing operators on a deployed SGP.02 device required a complex SM-SR transfer procedure – effectively a handover of device management rights from one operator’s infrastructure to another. In practice, this was so cumbersome that many deployments simply stayed with the original operator for the device’s entire lifetime, negating the commercial benefit of remote operator switching.

Second, no multi-operator flexibility. A single SM-SR could not easily coordinate profiles from competing operators. Multi-operator deployments required either multiple SM-SR relationships or a connectivity platform that abstracted the complexity – adding cost and reducing transparency.

Third, operator dependency for management. Because the SM-SR was operator-adjacent infrastructure, the enterprise had limited direct control over its own device fleet. Management actions depended on the operator’s systems and SLAs.

The eIM resolves all three. It sits as an independent management layer above the operator infrastructure, coordinates with multiple operators’ SM-DP+ servers directly, and is portable – meaning the enterprise’s relationship with the eIM platform is separate from its relationships with the mobile operators whose profiles that eIM manages.

eIM Portability: Why It Matters More Than It Sounds

eIM portability is the SGP.32 feature that receives less attention than it deserves. In SGP.02, the SM-SR created a binding between the device and a specific platform that was effectively permanent for the device’s deployed lifetime. Changing SM-SR provider required physical SIM replacement or complex migration procedures – neither acceptable at scale.

SGP.32 defines a standardised eIM transfer procedure. A device fleet can be migrated from one eIM platform to another without physical access to any device. The eIM transfer is coordinated at the server level – the current eIM and the receiving eIM authenticate with each other, transfer device management rights, and the devices themselves transition transparently on their next active window.

For enterprises evaluating eSIM management platforms, this changes the commercial dynamic significantly. You are not making a permanent hardware-lifetime commitment to a single platform when you deploy SGP.32 devices. You are choosing an eIM platform for its current capabilities and commercial terms, with the option to migrate if better options emerge. That is a meaningful difference from the lock-in model that characterised previous generations.

For a detailed technical walkthrough of how eIM portability works in practice, see the eIM portability guide at SGP32.co.uk.

The IPA: The On-Device Half of the eIM Relationship

The eIM is the server side. The IPA (IoT Profile Assistant) is its counterpart on the device. The IPA receives commands from the eIM, communicates with the eUICC to execute profile operations, and reports status back. It replaces the LPA (Local Profile Assistant) from SGP.22 – with the critical difference that the IPA requires no user interaction.

SGP.32 defines two IPA variants with different hardware implications:

The IPA-e approach is particularly significant for large-scale sensor deployments where the end devices genuinely cannot run the IPA stack themselves. The gateway handles eIM communication on behalf of the sensor cluster, making SGP.32 management viable across a heterogeneous fleet with widely varying device capabilities.

The full IPA-e vs IPA-d comparison – including which deployment architectures suit each variant – is covered at SGP32.co.uk.

How the eIM Fits Into the SGP.32 Architecture

The full SGP.32 architecture has four primary components. Understanding how the eIM sits relative to the others makes its role clearer.

The eIM’s position in this stack – above the operator infrastructure but below the enterprise application layer – is what gives it both its flexibility and its significance. It is the control plane for the entire IoT SIM estate. The full SGP.32 architecture breakdown at SGP32.co.uk maps all four components and their interfaces in detail.

What the eIM Means for IoT Fleet Management Today

SGP.32 hardware – certified modules with IPA-d or IPA-e support – is reaching commercial availability through Quectel, Thales (Cinterion), and others through 2025-2026. Most IoT devices in the field today run SGP.02, SGP.22, or physical SIMs. The eIM as an SGP.32 management layer is a forward architecture – the right foundation for new hardware designs, not a retrofit for existing fleets.

That said, the operational principles the eIM embodies – centralised remote profile management, multi-operator flexibility, server-initiated provisioning, no physical SIM access required – are exactly the outcomes that IoT fleet managers need right now. For current deployments on physical IoT SIM cards, multi-network IoT SIMs from IoTSIMs.co.uk provide the network flexibility and management capability that the market requires while the SGP.32 hardware ecosystem matures.

For organisations planning new hardware designs or multi-year deployment programmes, building eIM-ready architecture into the specification now – selecting SGP.32-capable modules where available, choosing eIM platforms with documented portability support, and planning connectivity strategy around the operator flexibility SGP.32 enables – is the right approach.

eIM Security: The Platform That Manages Everything Is the Platform That Must Be Secured

The eIM’s centralised control over an entire IoT SIM estate makes it a high-value target. An eIM platform compromise does not just affect one device – it potentially affects every device under management. Platform security is therefore a first-order requirement, not an afterthought.

The key security requirements for an eIM platform are:

The eSIM security landscape – covering eIM attack surface, bootstrap security, and defensive architecture – is covered in detail at SGP32.co.uk’s eSIM security guide.

Further Reading

Powered by
►
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
►
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
►
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
►
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
►
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
None
Powered by