There’s been a lot of noise around SGP.32 lately. If you’ve been following the IoT connectivity space, you’ve probably seen it positioned as the next big unlock for global deployments. But here’s the reality: standards don’t solve problems on their own. Execution does.

That’s exactly where Eseye is trying to position itself with its latest move. The company has announced the integration of SGP.32 into its AnyNet+ eSIM and Infinity Connectivity Management Platform, effectively bringing the new GSMA standard into a managed, real-world deployment model.

And that distinction matters more than most headlines suggest.

SGP.32 is here. But it’s not a silver bullet

Let’s start with the basics. SGP.32, developed by GSMA, is the latest Remote SIM Provisioning (RSP) standard built specifically for IoT. Unlike earlier standards like SGP.02 and SGP.22, it’s designed for constrained devices. Think sensors, trackers, low-power endpoints that don’t have the luxury of full connectivity stacks.

On paper, it solves a major challenge: remotely managing connectivity across devices that are often deployed globally and rarely touched again.

But even industry analysts are already pushing back on the hype. Transforma Insights recently pointed out that SGP.32 is not a “magic wand.” And they’re right.

Because provisioning a SIM profile is only one piece of the puzzle. What happens when networks fail? When do roaming agreements shift? When regulatory rules change mid-deployment?

That’s where things usually break.

Orchestration becomes the real battleground

What Eseye is doing here is less about “supporting SGP.32” and more about wrapping it in something that actually works at scale.

The key concept introduced by SGP.32 is the eSIM Orchestrator (eSO). In theory, this role manages profile lifecycle, network selection, compliance, and billing. In practice, it becomes the control layer for global connectivity.

Eseye’s Infinity platform is designed to play exactly that role.

Instead of treating SGP.32 as a standalone feature, they’re combining it with:

• Multi-IMSI for network flexibility
• Intelligent fallback to avoid outages
• Bootstrap connectivity for initial provisioning
• Managed orchestration across networks and regions

This is where the story shifts. Because resilience in IoT is not about switching profiles. It’s about never losing connectivity in the first place.

And that requires orchestration, not just standards compliance.

Multi-IMSI is still doing the heavy lifting

One thing that stands out in Eseye’s approach is that SGP.32 isn’t replacing existing models. It’s being layered on top of them.

That includes multi-IMSI, which remains one of the most practical tools for maintaining uptime across multiple networks.

While SGP.32 defines how profiles are delivered, it doesn’t guarantee what happens after deployment. There’s no built-in mechanism for ensuring uptime, handling network failures, or maintaining performance.

Eseye fills that gap by combining:

• Multi-network access across 800+ networks
• Coverage in 190 countries
• Managed fallback logic
• Operational guardrails

The result is closer to what enterprises actually need: continuity, not just flexibility.

The “DIY SGP.32” trap

There’s another angle here that doesn’t get enough attention. The idea that SGP.32 will democratize IoT connectivity and give enterprises full control sounds appealing. Until you try to implement it.

Because once you move into a DIY model, you’re suddenly responsible for:

• Managing multiple operator contracts
• Handling regulatory compliance across markets
• Maintaining backend integrations
• Orchestrating profile lifecycle changes
• Preventing devices from getting stranded

That’s not a connectivity problem anymore. That’s an operational one.

Eseye is clearly pushing against this narrative, positioning managed orchestration as the safer and more scalable approach.

As Ian Marsden, CTO and Co-Founder at Eseye, puts it:

“SGP.32 is an important step forward for IoT, but true resilience depends on how it’s implemented. By integrating SGP.32 into our Infinity platform and AnyNet+ eSIM, Eseye delivers multi-network continuity, fallback and orchestration guardrails – so enterprises get the resilience they need without having to become connectivity experts or effectively run their own MVNO.”

He goes even further:

“However, the industry should be careful not to confuse remote provisioning with operational resilience: giving customers a red button to switch networks without the right guardrails may sound empowering, but in practice it can increase risk, complexity and the chances of self-inflicted outages.”

That’s probably one of the most honest takes on SGP.32 so far.

What enterprises should actually care about

If you strip away the technical framing, the key takeaway is pretty simple.

SGP.32 is useful. But only in the right context.

It works particularly well for constrained IoT devices, especially those using lightweight protocols like CoAP or LwM2M. It simplifies provisioning and enables more flexible deployment models.

But it doesn’t remove complexity. It shifts it.

That’s why most enterprises will likely adopt SGP.32 as part of a managed service rather than running it themselves. The combination of multiple RSP standards, evolving regulations, and operational risk makes a unified orchestration layer almost non-negotiable.

The smarter approach is not choosing between SGP.02, SGP.22, or SGP.32. It’s building a framework that can support all three as the ecosystem evolves.

Where this sits in the broader market

Eseye is not alone in this direction. The entire eSIM and IoT connectivity space is moving toward orchestration-led models.

Players like Thales, IDEMIA, and Kigen are building around provisioning and security. MVNOs and connectivity platforms are expanding into lifecycle management. And newer API-driven players are pushing toward programmable connectivity.

What’s emerging is a clear shift:

From connectivity as a product → to connectivity as infrastructure.

And in that model, orchestration becomes the real differentiator.

Final thoughts about Eseye SGP.32 IoT connectivity

The SGP.32 conversation is still in its early stages, but one thing is already clear: the winners won’t be the ones who implement the standard first. It will be the ones who make it usable at scale.

Eseye’s approach reflects a broader industry reality. Enterprises don’t need more control in isolation. They need systems that absorb complexity, not expose it.

SGP.32 will play a role, especially for next-generation IoT deployments. But it won’t replace the need for multi-network strategies, managed services, and intelligent orchestration.

If anything, it makes them more important.

Because in global IoT, the real challenge has never been provisioning a connection.

It’s keeping it alive.