Eseye and SGP.32: Where the Orchestration Lock Lives

The short version: Eseye is the clearest UK example of where SGP.32 moves the lock-in rather than removing it. The standard hands enterprises the freedom to switch networks over the air. Eseye’s argument, made plainly by its own CTO, is that the freedom is close to useless without the orchestration layer that sits on top of it – and that orchestration layer is the product. Understand Eseye and you understand why “no more operator lock-in” is a half-truth: the lock did not disappear, it relocated to the control plane.

Who Eseye actually is

Eseye is a Guildford-based global IoT connectivity specialist, founded in 2007 and best known for two things: its AnyNet+ eSIM, which is designed to roam across a large pool of underlying networks, and its Infinity connectivity management platform, which does the day-to-day work of provisioning, switching and keeping fleets online. The company runs north of ten million connections and acts as the standardised global eSIM behind several tier-one operators, AT&T and TELUS among them. It is venture and debt backed rather than operator owned, which matters to its positioning: Eseye sells itself as the neutral layer above the networks, not as anyone’s captive channel.

Leadership is worth naming because the people set the tone of the argument. Tony Byrne, a former COLT and BT Broadband executive, runs the commercial story. Ian Marsden, co-founder and CTO, runs the technical one – and he is the more interesting voice for anyone trying to see past the press releases.

What Eseye brings to SGP.32

On 22 April 2026 Eseye announced that it had folded SGP.32 into AnyNet+ and Infinity, positioning itself as one of the first major connectivity players to manage all three GSMA remote provisioning standards – SGP.02, SGP.22 and SGP.32 – from a single interface. In architectural terms, Infinity takes on the eSIM Orchestrator (eSO) role: the layer above the eIM that handles profile lifecycle, network selection, compliance and billing.

That “one interface for all three standards” framing is the whole strategy in a sentence. Eseye is not betting that the world flips cleanly to SGP.32. It is betting the opposite: that real fleets will run a mixed estate of legacy SGP.02, consumer-derived SGP.22 and new SGP.32 devices for years, and that whoever owns the console that manages the mess owns the customer. The standard is treated as a feature of the platform, not the platform itself.

Underneath the orchestration sit the things Eseye has always sold: multi-IMSI for network redundancy, intelligent fallback when a network drops, and a managed pool of profiles across hundreds of carriers. SGP.32 slots into that as one more provisioning mechanism, not a replacement for it.

The story behind the facts

Here is where Eseye becomes genuinely useful to understand, because its own CTO is refreshingly unwilling to sell SGP.32 as magic.

Ian Marsden’s line, repeated across the April coverage, is that the industry should not confuse remote provisioning with operational resilience. Handing an enterprise “a red button” to switch networks, he warns, sounds like empowerment but in practice invites self-inflicted outages unless there are guardrails around it. His framing of the goal is telling: enterprises should get resilience “without having to become connectivity experts or effectively run their own MVNO.”

Read that argument closely and you can see the commercial logic underneath the technical caution. SGP.32 was pitched to the market as the end of vendor lock-in: no more being married to one operator’s SIM, no more truck rolls to swap it. Marsden is not disputing that. He is pointing out that the freedom SGP.32 grants is raw and, on its own, dangerous – and that taming it requires exactly the orchestration, fallback logic and operational guardrails that Eseye sells. Tony Byrne says the same thing from the commercial side: enterprises have moved beyond needing a basic SIM and now need “an intelligent orchestration layer” capable of handling SGP.32 complexity.

Both are right on the technical merits. A naive SGP.32 deployment, where an operator or integrator can flip a device’s profile with no continuity logic, really can strand a fleet. But notice what the argument does. It reframes the standard’s headline benefit – the freedom to switch – as a liability that only a platform can safely manage.

Where the lock-in actually moves

This is the conservation of lock-in in its clearest form. SGP.32 dissolves the bond between a device and a single operator. It does not dissolve the need for something to decide which network a device uses, when it fails over, how it stays compliant across borders and how it is billed. That decision-making layer is the eSO, and once your fleet’s operational behaviour is encoded in one vendor’s orchestrator, switching orchestrators is the migration nobody wants to run. The SIM got portable. The control plane did not.

None of this makes Eseye the villain of the story. The orchestration layer is real work and it delivers real value – the alternative, as Marsden correctly notes, is enterprises trying to run their own MVNO-grade operations. The point is analytical, not moral: when a vendor tells you SGP.32 ends lock-in, ask where the new lock is, because there is always a new lock. With Eseye, it is honest and visible. It lives in Infinity.

If you are evaluating Eseye

The applied questions that actually matter, most of which apply to any orchestration vendor, not just this one:

• Profile ownership. Whose profiles are in the fleet, and can you take them elsewhere if you leave the platform, or are they bootstrapped to Eseye’s ecosystem? This is the real portability question, and it sits below the SGP.32 marketing. See what to ask any eSIM provider.
• eSO exit. If you wanted to move your orchestration to a different eSO in three years, what does that migration actually involve? A vendor confident in its value will answer this cleanly.
• Guardrails, defined. Marsden is right that unguarded switching is dangerous. So pin down exactly which switching decisions the platform makes for you, which it lets you make, and which it forbids – because that boundary is where your operational control ends and theirs begins.
• Mixed-estate reality. If most of your near-term deployment is still SGP.02 or SGP.22, how much of the SGP.32 story is available to you today versus on a roadmap?

Where Eseye sits in the landscape

Among the UK players, Eseye is the orchestration anchor. Kigen holds the silicon and the eUICC OS; 1GLOBAL holds the bootstrap; Eseye holds the control plane above the eIM. If you are mapping the SGP.32 ecosystem by asking “where does the stickiness live for each vendor,” Eseye’s answer is the cleanest of the lot, because its own leadership will tell you: the value, and therefore the lock, is in the layer that manages the freedom the standard hands you.

By Peter Green