TechForge

31st March 2026

Over the last ten years, eSIMs have become one way that firms can manage international fleets of connected devices. Remote provisioning means devices can change profile without physical access, and companies can provision devices, change network provider, and respond to any regulatory changes that might affect them. The GSMA’s SGP.32 specification defines how profiles are pushed to devices and managed over time. Theoretically, interoperability between operators is simple.

Depending on the sector, governments can stipulate how machine identities are stored and where control functions can be based. Clearly, across multinational networks, there’s often little alignment between local policies: Some jurisdictions require local storage of subscriber data, others may insist on a need for lawful interception, or mandate that domestic, local operators are commercially involved. A single device can be subject to several sometimes conflicting obligations, and multinational fleets can become a tangle of competing (and changing) regulation.

At its heart, SGP.32 addresses technical problems rather than presenting operational solutions. It standardises remote SIM provisioning, defines roles like the eSIM IoT remote manager, and describes the interfaces used for profile management, for example. In principle, a device maker or enterprise should be able to manage connectivity through a common framework.

In the real world, implementation still varies, with vendors interpreting the specification differently. The goal of full, cross-provider interoperability is, in some cases, described charitably as ‘developing’. That’s not unusual for a standard that’s only recently been invoked. As SGP.02 takes its final bows, there is a limit on the extent to which firms can rely on SGP.32 as a single control layer.

Local vs. global

The best intentions of a company’s global strategy may founder on a need for local operators’ involvement, whether with local profiles or control points, or data storage, or a combination of the three. On the brighter side, some territories’ regulations are simpler to comply with, with network managers needing only to provide audit details and meet security conditions. Nevertheless, the variation from territory to territory weakens the theoretical simplicity that eSIMs are meant to provide.

Profile management and transaction records may fall under local data protection rules, so a single, centralised platform could fall foul of regulators. The default solution is to work with providers that offer local data hosting, which gets around some problems. But a global, all-encompassing control solution deteriorates into a patchwork of data access issues and routines having to be built to navigate third-party APIs. Ask any logistics operations manager about maintaining a unified supply chain and you’d expect a long and complex answer – and yet managers of enterprise-scale multinational IoT networks are finding themselves in the same situation.

As SGP.32 evolves to working maturity, it’s an area that’s still the subject of much discourse online and at industry events – we’ll be covering the IoT Tech Expo in May on these pages, for example – and at this stage of the life of SGP.32, the sector is keen to work out the kinks and fill in the detail as quickly as is sensible.

Managing a hybrid satellite-terrestrial network using eSIMs on a technical level may be (or become) simpler and offer global network operators choice, but the need for an adaptive and responsive orchestration layer is apparent – not as a box-ticking exercise or as an escape from the wrath of local regulators, but to retain operational resilience. There are a few organisations that have been quick to market with orchestration services for hybrid satellite-terrestrial networks in the first couple of years since SGP.32 was published. Among them are offerings from Aalyria, G&S SatCom, and Telenor IoT. We expect more to follow as standards evolve.

Security and regulatory considerations

Security expectations evolve, and regulators and customers expect strong control over device identity and the ability to trace any changes to connectivity. SGP.32 includes mechanisms for secure profile download and management, but assurance depends on the details of an implementation. Key pair management, logging, and access control are not included in SGP.32’s core specification and are left to individual vendors. Thus, two deployments that both claim compliance with SGP.32 may differ in their security posture.

A specific risk to the sector is that IoT devices remain in service for many years, often in locations where physical access is difficult. Remote provisioning can make profile changes, but long lifecycles aren’t necessarily compatible with regulatory changes or the latest crop of CVEs. Devices deployed under today’s assumptions will still have to comply with new requirements and security issues later down the line.

Updating a connectivity profile may not be enough to meet local strictures, and any control layer itself has to be adaptable. If there’s an assumption that compliance will lag behind regulations, there’s a degree of operational risk.

Change and adoption

Adoption of SGP.32 is by no means global and complete. While some operators and platform providers support it (or at least, interpret it), others stick to earlier specifications or, in the case of some, hang on to proprietary systems. The GSMA itself continues to refine SGP.32, and in general, any process of standardisation will is achieved through consensus.

The lack of a fully-uniform approach means support for SGP.32 can be patchy. Companies rolling out or updating fleets typically follow several integration paths at the same time, a process that increases costs and complexity (ironically, in order to achieve the goals of cutting costs and decreasing complexity).

The concept of global device control through a single eSIM framework needs to be treated with care by the enterprise decision-maker. SGP.32 provides a technical base and reduces many forms of fragmentation, but adaptation by global satellite-terrestrial network operators has to follow local rules on data, connectivity, and security.

Any broad, control model would include the ability to adapt to regional adaptations, adhere to governance on profile management etc., and respond to regulatory and security changes. Companies have to engage with operators and platform providers in all territories to understand how best to implement any solution. That’s an operational burden, but it is the current state of the market.

(Image source: WikiImages, via Pixabay, under licence here: https://pixabay.com/service/license-summary/)

 

Want to learn more about IoT from industry leaders? Check out IoT Tech Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and co-located with other leading technology events. Click here for more information.

IoT News is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.

About the Author

Writer and Podcaster

Joe Green is a writer and podcaster based in Bristol, UK. He specialises in issues around free and open-source software, networking, privacy, cybersecurity, and software development.

Related

12th October 2026

12th October 2026

9th October 2026

6th October 2026

Join our Community

Subscribe now to get all our premium content and latest tech news delivered straight to your inbox

Popular

6119 view(s)
2857 view(s)
2492 view(s)
2253 view(s)

Subscribe

All our premium content and latest tech news delivered straight to your inbox

This field is for validation purposes and should be left unchanged.