- Resources
- Blog
- News
SGP.32 Reality Check: What to look for in IoT eSIMs?
Bee Hayes-Thakore In Part 1 of the SGP.32 Reality Check series, we covered what happened when IoT Stars put SGP.32 through an independent reality check using Kigen eSIMs, Kigen eIM, Kigen Pulse, Secure with Kigen hardware, and live MVNO profiles from Kigen MVNO partners.
That first article showed the headline finding: SGP.32 is no longer just a standards discussion. It can be tested and used across real hardware, real connectivity profiles, and real remote management workflows. We extended some learnings on how one can develop now with real choice and interoperability. Now we turn to how decision makers can take the development work and ensure that the choices and nuances work for you when you need to ramp quickly to scale.
This second article looks at the next question enterprises should ask before choosing an IoT eSIM vendor: what should you look for in SGP.32 eSIMs so that they meet your business needs in the long run?
That matters because the IoT Stars test was not built on a special proof of concept. From Kigen’s side, it was important that IoT Stars used the same tools, support paths, eSIM software configuration, and remote management capabilities that customers can access through a standard business inquiry. The Kigen eSIMs, Kigen eIM, Kigen Pulse, and Kigen APIs used in the test reflected commercial deployment paths, not a one-off lab environment.
The same was true for the connectivity profiles. With the support of Onomondo, Soracom, and ZARIOT, IoT Stars used MVNO profiles of the same quality and configuration available for real customer use today.
That is why the Reality Check matters. It did not simply ask whether SGP.32 works in principle. It showed how commercially available eSIMs, remote management tools, hardware, APIs, and MVNO profiles work together in practice.
Why implementation matters among certified SGP.32 products
As SGP.32 products enter the market, certification becomes the starting point for evaluation, not the final answer. Certification helps confirm that a product has met defined testing achieving the security assurances. But for enterprises deploying connected products at scale, the next question is more practical: how can the implementation support the realities of IoT deployment that is right for them?
Two SGP.32 products can follow the same standard while making different choices about architecture, interoperability, device-side integration, transport support, profile operations, and lifecycle management. Typically, these are apparent from the comparison of the declarations of certified products such as GSMA Compliance Confirmation of Product Declaration for Kigen products:
For example, the location of the IoT Profile Assistant, or IPA, can affect hardware flexibility and certification pathways. Support for indirect profile download can matter for devices behind gateways or inside restricted networks. Transport options can influence performance in constrained environments. API design can determine how easily eSIM management fits into enterprise systems. Auditability can affect security governance, compliance, and support.
In other words, SGP.32 certification tells you the product is built to the standard. Implementation tells you whether it is built for your deployment.
What to look for in an SGP.32 eSIM and remote managment stack?
Here’s a quick simple guide to additional capabilities to evaluate what is best fit for your IoT eSIM needs:
1. Indirect profile download
Indirect profile download is important for critical infrastructure and constrained IoT environments where endpoints may not connect directly to the public internet.
Many devices sit behind gateways, operate inside restricted networks, or follow strict security policies. With a suitable eIM supporting indirect profile download, enterprises can extend secure profile management to devices that would otherwise be difficult to reach, update, or manage.
For industrial, utility, and infrastructure use cases, this is not an edge case. It is often the operating model.
2. Transport-agnostic secure delivery
IoT deployments vary widely. Some devices use broadband connections. Others operate over constrained or low-power networks. A strong SGP.32 implementation should not depend on legacy assumptions about transport.
SGP.32 enables secure profile delivery over IP-based transports such as HTTPS/TCP or CoAP, rather than relying on older SMS-based trigger commands. For broadband environments, HTTP/TCP/TLS may be appropriate. For constrained or LPWAN environments, CoAP/UDP/DTLS may be better suited.
The point is straightforward: secure profile delivery should fit the deployment model, not force the deployment to work around the eSIM stack.
3. Certified, auditable, and traceable operations
Security cannot be assumed. It has to be demonstrated.
Kigen has certified its eSIMs to the GSMA eSA scheme, meeting security benchmarks for both Consumer and IoT eSIMs. For enterprises, this matters because profile operations are security-sensitive lifecycle events. Downloading, enabling, disabling, or deleting a profile can affect connectivity, commercial policy, device identity, and operational continuity.
Auditability is equally important. At fleet scale, teams need to know which profile was downloaded, which profile was enabled, when an operation occurred, and whether it completed successfully. For regulated or business-critical deployments, this visibility becomes part of operational governance.
Kigen has also declared its approach to security updates to ENISA, which has oversight for Cyber Resilience Act compliance. For companies designing connected products for the European market, secure lifecycle management is becoming a core requirement.
4. Tested interoperability
No enterprise wants to be locked into a single vendor.
CoAP Support for NB-IoTA strong eIM should work with different SM-DP services and help bridge the ecosystem as it evolves. Kigen eIM is designed to work with SM-DP services, while binding and transport protocol translation help maximize interoperability, including access to legacy SM-DP+ services that do not have built-in support for indirect profile download.
Interoperability also needs to be tested beyond one vendor’s own stack. Kigen’s eIM has been tested with eUICCs from other vendors, and Kigen eUICCs have been tested with five other eIMs, including publicly referenced work with Simplex Wireless.
For enterprise deployments, these details should be validated before devices reach production.
Why IPAe changes the hardware conversation
One of the most important implementation choices in SGP.32 is the location of the IoT Profile Assistant, or IPA. In the consumer RSP world, the equivalent was the Local Profile Assistant or LPAd. Learn about the differences between LPA or IPA here.
The IPA is the device-side function that communicates with provisioning servers. It can be implemented in the eUICC as IPAe, or in the device or modem firmware as IPAd.
Availability of IPAe within certified eSIMs gives product teams a practical advantage. When the eUICC contains the trust anchor and IPAe, the eSIM can provide a versatile foundation for many network operator requirements. It can also help meet higher security expectations through the GSMA eSA security scheme and Common Criteria-based assurance.
This can widen hardware choice and reduce integration friction. Additional full device certification may still be required by network operators, depending on the device and deployment. However, for many IoT-class devices, IPAe can make the certification and integration path more straightforward.
Why further stack integration matters
The Reality Check showed that SGP.32 is not just about downloading a profile. It is about making profile management reliable across the device lifecycle.
That requires integration across eSIMs, eIM orchestration with Kigen Pulse, APIs, connectivity profiles of your choice, hardware modules that offer great design experience, device-side software, and enterprise backend systems.
When these layers are tested together, enterprises can reduce operational mismatches moving from initial launch to Day 2 operations. Without that integration, a device may show one active profile while billing, policy, or connectivity systems treat it differently. At fleet scale, those mismatches create cost, support, and compliance risk.
An integrated stack helps profile operations follow business policy. A device can use the right profile, in the right region, with the right data package, under the right operational controls.
Further, the IoT Stars demo also shined a light on the power requirements.
From reality check to real deployment
The strongest proof point for any IoT technology is not the specification. It is adoption.
Kigen’s work with customers and partners shows that SGP.32 is moving from early experimentation toward operational deployment. Digi and Itron are already using Kigen integrations in volume, and the broader Kigen ecosystem continues to grow across device makers, connectivity providers, and platform customers.
As Counterpoint Technology Market Research’s Mohit Agrawal noted in his assessment of Kigen’s ecosystem momentum:
“
The proof of success of any initiative lies in the numbers. As a result of its focus on partnerships and the ecosystem, Kigen has been able to achieve the following:
🔀 A platform customer making 3 Million API calls to Kigen Pulse for eSIM orchestration
⌚ A global brand manufacturing with full eSIM provisioning in under 2 mins
🏁 A major consumer device maker is becoming eSIM native with its new products, with a run rate of over 500,000 devices/yr and ramping up
🚀 3 specialist brands with bulk market share in their vertical, adopting Kigen eSIMs across their product portfolio.
𝗠𝘆 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆:
The winners in the SGP.32 era will not just be companies with strong technology. They will be those who build interoperable ecosystems and execute through partnerships.
In that context, Kigen’s expanding partner network is a strong signal that the SGP.32 ecosystem is starting to move from early experimentation to large-scale operational deployments.”
-Mohit Agrawal, Counterpoint Technologies. See in full.
That is what the IoT Stars Reality Check demonstrated.
The technical barriers are falling. The standard is mature. The hardware ecosystem is growing. The connectivity ecosystem is ready. Digital activation codes are available. Remote profile operations can be managed through Kigen Pulse or integrated through APIs.
The question is no longer whether SGP.32 can work.
The question is: what will you build with it?
In case you need a reminder, here’s some of the recommendations Loic Bonvarlet shared. We’d recommend the full viewing where the credit goes to attendees who had brilliant questions!
Again, with thanks to IoT Stars community, our connectivity partners and Secure with Kigen hardware partners for joining in this effort to make SGP.32 eSIM adoption simple to develop and scale:
We partner with the best! If you want to be featured, get in touch via our partnerships page.
Content Authenticity Statement
The research, structural outlining, and content for this article were generated by the author. AI tools were used for proofreading and adjustments to ensure the text can be translated into multiple languages. The final content was reviewed and edited by our team to ensure accuracy.
