GO UP
esim background

STMicroelectronics and COMPRION Tackle SGP.32 Interoperability

The IoT eSIM conversation has spent years talking about flexibility: one device, multiple network profiles, remote provisioning, less dependence on permanent roaming and fewer connectivity decisions locked in at the factory.

 

Now comes the less glamorous part — making sure all the pieces actually talk to each other.

STMicroelectronics and COMPRION are addressing that problem with a reference testing environment designed to help developers validate IPAd implementations for GSMA SGP.32-based IoT eSIM deployments. The setup combines STMicroelectronics’s physical ST4SIM-300 eUICC with simulated eIM and SM-DP+ functionality from COMPRION, alongside analysis and monitoring tools intended to expose interoperability problems before devices reach the field.

That may sound like a niche testing announcement. It is actually a useful sign of where SGP.32 is heading next: away from PowerPoint architecture diagrams and toward real implementation work.

Why the IPAd matters

SGP.32 was created for a problem that consumer eSIM never really had to solve.

A smartphone has a screen, an operating system, plenty of processing power and a user who can tap through an activation flow. A smart meter, industrial sensor or asset tracker may have none of those things. It can also spend years in the field on constrained networks such as NB-IoT.

The GSMA’s IoT architecture therefore introduces the eSIM IoT Remote Manager, or eIM, and the IoT Profile Assistant, or IPA. The IPA acts as the bridge between the eUICC and the wider remote-provisioning system. In the IPAd configuration, that software runs on the IoT device itself.

That creates freedom for device makers, but also responsibility. An IPAd developed by an OEM still has to behave correctly with the eUICC, eIM and SM-DP+ around it.

READ MORE: STMicro ST4SIM-300 eSIM complies with SGP.32 GSMA eSIM Standard for IoT

This is precisely where the STMicroelectronics-COMPRION environment comes in.

Developers can test their own IPAd implementations, whether they start from STMicroelectronics’s reference implementation or build one from scratch. The companies say the components have been tested together to create a known reference environment rather than leaving developers to assemble every part of the validation chain themselves.

The setup includes:

  • a physical ST4SIM-300 eUICC;
  • simulated eIM functionality from COMPRION;
  • simulated SM-DP+ functionality;
  • monitoring and analysis capabilities for examining the communication between components; and
  • an ST IPAd sample implementation that developers can use as a starting point.

ST currently describes the ST4SIM-300M as compliant with GSMA SGP.32 v1.2 and capable of remotely managing profiles from different mobile operators. The company completed GSMA certification for the product in 2025.

Telefónica SGP.32 eSIM

Catch problems before deployment

The practical value is fairly simple: developers get somewhere controlled to break things before customers do.

“This enables developers to verify interoperability between the IPAd and the eUICC under realistic conditions, identify potential issues early in the development cycle, and reduce integration risks before deployment. This will allow IoT and connectivity makers to bring solutions faster and easier to the market,”

said Agostino Vanore, Secure Edge & IoT eSIM Business Unit manager at STMicroelectronics.

For IoT manufacturers, early validation matters more than it might in a phone environment. A bad implementation in a smartphone can often be fixed with an app or OS update. A problem discovered after tens of thousands of meters, trackers or industrial devices have been installed across several countries is a much more expensive conversation.

READ MORE: Kigen unveils eIM solution for SGP.32 compatible with consumer eSIMs

And SGP.32 deliberately creates a more open architecture. That is one of its strengths, but openness only works if independently developed components remain interoperable.

The GSMA published SGP.32 v1.3 in May 2026, covering remote provisioning and management for network- and user-interface-constrained IoT devices. Its associated test framework sits within the SGP.33 family.

That makes test tooling increasingly important as more vendors move from pilots to commercial SGP.32 products.

More on Alertify
Follow the latest SGP.32 news
GSMA IoT eSIM standards, eIM remote provisioning, enterprise IoT fleet deployment, IPA architecture, and cellular IoT connectivity updates.

Explore news→

A wider interoperability race

ST and COMPRION are not operating in an empty market.

COMPRION itself announced a partnership with Thales earlier in 2026 around a standards-based SGP.32 validation environment covering eIM, IPA and eUICC interoperability. Kigen, meanwhile, is pushing a more integrated route with its own eIM, device C-SDK, IPAd tooling and IoT eSIM starter kit, while partnerships with companies such as Onomondo and KORE are moving SGP.32 into live connectivity propositions.

That distinction matters.

READ MORE: SGP.32 Moves From Specification to Linux Device Tooling

The STMicroelectronics-COMPRION approach should be especially interesting to OEMs, module makers and embedded-software teams that want to develop or validate their own device-side implementation. Companies simply looking for a turnkey managed connectivity service may prefer a more bundled eSIM, eIM and connectivity stack rather than investing engineering effort in IPAd development and testing.

There is also an obvious next step. STMicroelectronics’s current product documentation still references SGP.32 v1.2, while the GSMA has already published v1.3. For a reference environment whose value rests on reducing implementation risk, visibly keeping the tooling and certification path aligned with the latest specification revisions will be important.

Conclusion

SGP.32 does not win because another company says it supports remote profile switching. It wins when an eUICC from one supplier, device software from another, an eIM from somewhere else and an operator’s existing SM-DP+ can work together without months of custom integration.

That is why this collaboration is more meaningful than the hardware list suggests.

The first phase of SGP.32 was about defining a better architecture for IoT. The next phase is about proving interoperability at scale. STMicroelectronics and COMPRION are positioning themselves squarely in that second phase, alongside Thales, Kigen and a growing set of connectivity platforms.

The winners may not be the companies offering the biggest “SGP.32-ready” badge. They will be the ones that make implementation boring: testable, repeatable and predictable.

For industrial IoT, boring is exactly what good connectivity should become.

Driven by wanderlust and a passion for tech, Sandra is the creative force behind Alertify. Love for exploration and discovery is what sparked the idea for Alertify, a product that likely combines Sandra’s technological expertise with the desire to simplify or enhance travel experiences in some way.