Eseye has announced the integration of SGP.32 capabilities directly into its existing AnyNet+ eSIM product and Infinity Connectivity Management Platform. The move positions Eseye as one of the first major IoT connectivity players to offer all three GSMA RSP models – SGP.02, SGP.22, and SGP.32 – from a single managed interface.
The announcement, published on 22 April 2026, marks a significant step in SGP.32’s commercial maturation. For the past two years, SGP.32 has existed largely as a specification and a handful of early-adopter deployments. Eseye folding it into a production-grade managed connectivity platform signals that the standard is now enterprise-ready at scale.
You can read the full announcement on the Eseye website.
What Eseye Has Actually Built
The integration centres on Eseye’s Infinity platform taking on the eSIM Orchestrator (eSO) role defined in the SGP.32 architecture. This means Infinity now handles profile lifecycle management, network selection, compliance oversight, and unified billing across SGP.32 deployments – the same functions it already performs for SGP.02 and SGP.22.
Critically, Eseye has not simply bolted SGP.32 onto its existing stack. The approach combines SGP.32 remote provisioning with its proven multi-IMSI capability, bootstrap connectivity management, and network orchestration guardrails. The intent is to prevent the failure modes that a standalone SGP.32 deployment can introduce – profile switching without fallback, network gaps during provisioning, and the risk of devices becoming stranded in the field.
The platform supports a broad ecosystem of RSP providers including Thales, IDEMIA, and Kigen, maintaining Eseye’s vendor-agnostic positioning across the RSP supply chain.
The Three-Standard Problem
Understanding why this announcement matters requires understanding the RSP landscape. SGP.02, SGP.22, and SGP.32 are not interchangeable – they were built for different device classes, network environments, and operational models.
SGP.02 was the original M2M standard. It works for automotive and high-value connected devices but carries operator lock-in and complex SM-SR infrastructure requirements that make it unsuitable for mass IoT deployments.
SGP.22 solved the consumer problem. Its QR code and Local Profile Assistant model works perfectly for smartphones but assumes a user is present to initiate every profile change – an assumption that fails completely for a deployed utility meter or remote sensor.
SGP.32 was built specifically for IoT: server-initiated provisioning, CoAP over UDP for constrained networks, and the eIM architecture that removes operator lock-in from the device itself. But it is a new standard, and enterprises have existing fleets running SGP.02 and SGP.22 that are not going anywhere.
Eseye’s platform managing all three from one interface is a practical answer to a real enterprise problem – legacy continuity alongside forward migration, without running separate platforms or renegotiating the entire supplier chain.
The Bootstrap Question
One area the announcement touches on but does not dwell on is bootstrap connectivity. Getting a device online before it has a production profile is one of the more practically awkward problems in SGP.32 deployment. Eseye’s managed service includes bootstrap handling as part of its connectivity orchestration, which matters more than it sounds.
The bootstrap catch-22 – a device needs connectivity to download a profile, but it needs a profile to get connectivity – is an operational problem as much as a technical one. Managed bootstrap providers with appropriate initial connectivity are a prerequisite for any real-world SGP.32 deployment at scale.
The DIY Risk Warning
Ian Marsden, CTO and Co-Founder at Eseye, made a point in the announcement that is worth quoting directly. He drew a distinction between remote provisioning capability and operational resilience, warning that giving enterprises a switch without the right guardrails can increase risk rather than reduce it.
This is not just a sales message. The DIY complexity concern around SGP.32 is real. The standard defines the mechanics of profile delivery, but it does not define network fallback behaviour, multi-operator commercial agreements, regulatory compliance for data sovereignty, or the operational processes needed to prevent self-inflicted outages. Without a managed layer above the standard, those responsibilities fall entirely on the enterprise.
The orchestration layer – not the profile management standard itself – is where the operational value sits. This theme maps directly to the wider question of where the real hero in eSIM delivery actually is: hardware, network, or the management platform above them both.
What Transforma Insights Said
Eseye references a Transforma Insights paper in the announcement, noting the analyst firm’s position that SGP.32 is not a magic solution to multi-country IoT connectivity challenges. Commercial contracts, back-end processes, regulatory compliance, and ongoing connectivity management remain essential regardless of which RSP standard is in use.
This matters for enterprises evaluating SGP.32 timelines. The standard is commercially viable and hardware is increasingly available, but the operational infrastructure around it – orchestration platforms, managed services, bootstrap providers, compliance frameworks – is where deployment success or failure is determined.
Key Considerations Eseye Highlights
The announcement includes a list of considerations for enterprises evaluating SGP.32. Several are worth highlighting here:
SGP.32 is particularly well suited to constrained devices – those without SMS capability, or running LwM2M or CoAP – where its pull-based provisioning model has clear technical advantages over earlier standards.
Most enterprises will engage with SGP.32 through a managed service rather than a DIY approach, given the complexity involved in managing multiple network profiles, commercial contracts, and technical configurations simultaneously.
Remote SIM provisioning works best when used strategically – for initial localisation, lifecycle management, and resilience – rather than as a mechanism for frequent commercial profile switching, which can introduce as much operational complexity as it removes.
Migration between SGP.02, SGP.22, and SGP.32 should be treated as a managed transition within a common orchestration framework. Physical and technical constraints mean it is not always seamless, but a unified platform makes it more controlled.
eSIM Management Platforms – The Next Layer
The Eseye announcement underlines a trend that is becoming clearer across the SGP.32 space: the standard enables new capability, but the value is realised through the management and orchestration layer sitting above it.
Dedicated eSIM IoT management platforms are emerging to address exactly this need – providing the interface layer between enterprises and the underlying RSP infrastructure. eSIM IoT Manager is one platform entering this space, focused on enterprise eSIM profile management and fleet orchestration for IoT deployments.
For a deeper look at why this orchestration layer matters and what it should provide, the SGP.32 missing layer analysis on sgp32.co.uk covers the gap between what the standard delivers and what enterprise operations actually require.
Where This Sits in the SGP.32 Timeline
The GSMA estimates 195 million SGP.32 profile downloads by 2029, representing around 70% of all IoT eSIM activity at that point. The Eseye announcement is one of several signals in early 2026 that the commercial ecosystem is now coalescing around the standard in a meaningful way.
Certified modules from Quectel and Thales Cinterion are reaching commercial availability. Managed service providers like Eseye are productising SGP.32 into their mainstream platforms. And the enterprise understanding of what the standard does – and does not – solve is maturing beyond the initial wave of press releases.
SGP.32 is not a replacement for operational expertise. It is a better technical foundation for building it on. The distinction matters increasingly as deployments scale.
Source: Eseye – Strengthens Global IoT Resilience with SGP.32 eSIM Orchestration (22 April 2026). For technical background on the SGP.32 standard, architecture, and hardware landscape, see sgp32.co.uk.