LibeSIM has added a new piece to the still-forming SGP.32 ecosystem: software that lets device makers actually implement and test eSIM profile management on Linux-based IoT hardware.

Common Creation, the Japanese company behind LibeSIM, launched an SGP.32-compliant IPAd for Linux devices on September 8, alongside an SGP.22 LPAd and an eUICC configuration utility. On paper, these are highly technical additions. In practice, they point to something much bigger: SGP.32 is moving out of standards documents and product roadmaps and into the implementation layer.

That matters because enterprise eSIM adoption will not be decided only by who can claim to “support SGP.32.” It will increasingly depend on how quickly device manufacturers, IoT platform providers and systems integrators can make the standard work inside real products.

The device-side gap

SGP.32 was created for IoT devices that often lack the screen, camera and user interaction assumed by consumer eSIM. The GSMA architecture introduces the eIM, or eSIM IoT Remote Manager, together with an IoT Profile Assistant, or IPA, which helps manage profile download and lifecycle operations. The GSMA published SGP.32 v1.3 in May 2026, covering remote provisioning and management for network- or user-interface-constrained IoT devices.

LibeSIM’s new IPAd puts that profile-assistant functionality directly on the device. According to the company, it can run on Linux-based IoT hardware and communicate with an eIM over cellular connectivity, Wi-Fi or wired LAN. It can then support operations including profile download, enablement and disablement.

READ MORE: SGP.32 Explained: IoT eSIM Fleet Operations in 2026

The launch includes three components:

• an SGP.32-compliant IPAd for Linux devices;
• an SGP.22-compatible LPAd for Linux;
• an eUICC configuration utility, including support for writing initial eIM configuration data.

The utility may sound like the least exciting part of the announcement, but it addresses a very practical problem. An SGP.32 deployment still needs the eUICC, eIM and device-side software to be configured correctly before anything useful happens. Reducing that integration work can make the difference between a standard being technically available and being realistic to deploy.

IPAd or IPAe?

The more strategically interesting point is LibeSIM’s support for both IPAd and IPAe architectures.

In an IPAd implementation, the IPA functionality sits on the device. With IPAe, it sits within the eUICC. The GSMA specification explicitly supports both modes, giving implementers some architectural flexibility.

LibeSIM previously supported the IPAe route through its SGP.32 eUICC. Adding IPAd means customers can now choose where that functionality lives depending on their hardware design, communications module and software environment.

READ MORE: emnify Launches Free SGP.32 Bootstrap for Global OEMs

That flexibility will matter. IoT is not one device category. A Linux industrial gateway, a battery-powered sensor and a connected vehicle do not have the same memory, power, operating-system or security constraints. Forcing the same implementation model across all of them would undermine one of SGP.32’s biggest promises: a more practical remote provisioning architecture for IoT.

There are limits. This particular tooling is aimed at Linux environments, so manufacturers working with lightweight RTOS platforms, deeply constrained embedded hardware or other operating systems will need different device-side options. Commercial deployment terms also remain case-specific; LibeSIM says the tools are available free to existing customers for evaluation, while production use is handled separately.

Implementation becomes the battleground

The wider market is already moving in this direction.

IDEMIA Secure Transactions has a GSMA-certified end-to-end SGP.32 stack spanning eSIM and eIM, and in 2026 announced a commercial SGP.32 deployment with Tele2 IoT and Cisco. Kigen has been building around the same implementation problem from another angle, combining its eIM with an embedded C SDK and participating in a multi-vendor SGP.32 test involving live connectivity profiles and several hardware platforms.

Eseye, G+D, Thales, 1oT and others are also developing or commercialising SGP.32-oriented platforms. The result is a market that is quickly moving beyond simple standards compliance. Buyers will soon have to compare implementation effort, interoperability, supported hardware, orchestration, certification status and how much custom engineering is required on the device itself.

READ MORE: Transatel Brings Zero-Touch eSIM to IoT Hardware

That is where LibeSIM’s Linux tooling fits. It is not necessarily the obvious choice for a multinational enterprise looking for a fully certified, globally deployed connectivity stack. Larger players already have broader production ecosystems, certification portfolios and international connectivity relationships.

But for device manufacturers, systems integrators and IoT developers that need to prototype SGP.32 on Linux without building every component from scratch, this is a more interesting proposition.

What would strengthen the offer is independent interoperability evidence. The functionality announced here is company-reported, and Alertify has not independently tested the tools. Public multi-vendor testing, certification details and documented integration results would make it easier for enterprise buyers to judge how well the implementation performs outside LibeSIM’s own stack.

Final thoughts

SGP.32 is reaching the stage where implementation quality matters more than specification awareness.

The GSMA’s current SGP.32 v1.3 formalises an architecture that is already attracting certified platforms, commercial deployments and multi-vendor testing. The next competitive layer is much less glamorous: SDKs, profile assistants, configuration utilities, hardware compatibility and integration time.

That is precisely why this LibeSIM launch is worth watching. It does not change the SGP.32 standard. It makes one part of the standard easier to put on an actual Linux device.

For enterprise eSIM buyers, that is an important shift in how vendors should be assessed. “Do you support SGP.32?” is rapidly becoming too weak a question.

The better question is: “How much work will it take us to deploy it?”