SGP.32 has crossed an important line in 2026: it is no longer mainly a standards story. Telenor IoT began commercial delivery of SGP.32 SIMs in April, Axentia became its first announced deployment customer, and G+D’s implementation in Amazon’s eero Signal is among the early commercial products using the architecture. The question is moving from “does SGP.32 work?” to a harder one: “does your particular combination of SGP.32 components work together reliably in the field?”

That is the uncomfortable takeaway from a new field analysis by Brian Day, VP of Technical Sales at floLIVE, published by IoT For All. Day argues that certification of individual components does not automatically prove that a complete multi-vendor deployment will interoperate without friction. Optional parameters, supported functions and implementation choices can still vary between vendors.

That does not mean the GSMA specification is failing. Quite the opposite. It means SGP.32 is entering the phase every serious infrastructure technology eventually reaches: the lab passes, the certificates arrive, and then thousands of real devices start doing inconvenient things.

Compliance is only the first test

SGP.32 was built for IoT devices that may have no screen, no user and unreliable connectivity. Its architecture separates functions that consumer eSIM normally keeps close together. The eIM remotely manages profile operations, while the IoT Profile Assistant, or IPA, sits in the device or eUICC and carries out local profile-management tasks.

The GSMA now lists SGP.32 version 1.3 as active, published in May 2026. Its compliance framework includes separate SGP.33 test plans for the eUICC, IPA and eIM. Interestingly, the GSMA currently maps SGP.32 v1.3 to the v1.2 generation of those test specifications, another reminder that standards, certification tooling and commercial implementations do not always advance in perfect lockstep.

READ MORE: SGP.32 in 2026: Automotive eSIM Meets Reality

What certification establishes is a baseline against defined requirements and tests. What an enterprise actually deploys, however, is a chain: eUICC, IPA firmware, eIM, SM-DP+, device software, modem behaviour and live connectivity. The chain is what has to survive production.

That is why the more useful buying question is no longer simply, “Are you SGP.32 compliant?” It is: “Which combinations have you actually tested?”

The IPA deserves more attention

Day’s strongest field claim is that the IPA is the “most common point of failure.”

That claim needs context. IoT For All provides no deployment count, sample size, failure-rate table or independent dataset, so it should be treated as experienced practitioner evidence, not an industry-wide benchmark.

Still, the wider market is moving in the same direction: test the complete path, not just the component.

In March, COMPRION and Thales announced an end-to-end SGP.32 validation environment covering eIM, IPA and eUICC interaction. More recently, COMPRION and STMicroelectronics introduced a reference environment specifically aimed at testing IPAd implementations across eUICC, eIM and SM-DP+ components. Kigen and IoT Stars have also demonstrated live profile migration across five different hardware devices and connectivity profiles from multiple providers.

READ MORE: STMicroelectronics and COMPRION Tackle SGP.32 Interoperability

This is a strong market signal. Interoperability testing is becoming a product category of its own.

For buyers, a sensible cross-vendor test matrix should include:

• every production eUICC and IPA firmware combination;
• each eIM and SM-DP+ pairing expected in service;
• interrupted downloads and provisioning-session recovery;
• unreachable-device behaviour, retry limits and back-off logic;
• profile-state conflicts and server/device reconciliation;
• firmware upgrades that change IPA behaviour; and
• measured provisioning success and failure rates, not only pass/fail certification status.

The last point matters. A platform that succeeds 99.9% of the time and one that succeeds 97% of the time may both look fine in a demonstration. Across one million remote profile operations, they are very different operating models.

Recovery is the real enterprise feature

SGP.32’s commercial promise is flexibility: remote profile changes, less physical intervention and more freedom to change connectivity over a device’s lifetime. But large IoT estates are messy. Devices sleep. Batteries run low. Coverage disappears. Sessions stop halfway through. Firmware versions fragment.

So the differentiator may become less about whether a platform can initiate a profile switch and more about what happens after a switch does not finish cleanly.

READ MORE: What Is “eSIM SGP.32” — And Why Should You Care?

The eIM needs to know whether a command was received, whether the eUICC changed state, whether the device disappeared mid-session and when another attempt is safe. Reconciliation cannot be an afterthought. Day specifically argues that infrastructure should anticipate unreachable devices, interrupted sessions and automatic recovery rather than expecting the endpoint to repair the state itself.

For a small, static fleet using one operator profile for its entire life, this sophistication may be unnecessary. An integrated single-vendor stack can also reduce interoperability exposure, although buyers trade some supplier flexibility for that simplicity. Multi-vendor SGP.32 becomes most valuable when long device lifetimes, multiple markets, regulatory change or future operator switching make optionality worth the additional engineering.

Conclusion: “Compliant” is becoming the starting line

The SGP.32 market is maturing in a healthy direction. Telenor, G+D, Thales, Kigen, STMicroelectronics and others are moving the conversation from architecture diagrams to deployed products, reference environments and live switching.

But that progress raises the procurement bar. Enterprises should stop treating “SGP.32 compliant” as a sufficient answer and start asking vendors to show the test matrix, firmware coverage, recovery logic and actual provisioning failure rates behind the claim.

The industry could help itself here. Public interoperability reports remain thin, and vendors rarely publish sample sizes, error distributions or recovery performance. Those numbers would be far more useful to an enterprise buyer than another logo saying “ready.”

SGP.32 is not being undermined by these early interoperability issues. It is being normalized. The winners will not be the vendors that merely support the standard. They will be the ones that can prove the whole stack keeps working when the network, device or software does not behave perfectly.