SGP.32 vs SGP.22: What floLIVE’s Journey Tells Us About IoT eSIM

Most SGP.32 vs SGP.22 explainers stop at the spec sheet: one standard is for phones, the other is for IoT, job done. That is true, and it is not much use if you are trying to decide what to put in a device that will be in the field until the mid-2030s. A better way to understand the difference is to watch a real connectivity provider live through it. floLIVE, the London and Israel-based IoT connectivity company, is a good case study: it spent its first decade engineering around the limits of the older eSIM standards, and in 2026 it rebuilt its proposition around SGP.32. Its story maps the past, present and likely future of both specifications rather neatly.

SGP.32 vs SGP.22 at a glance

• SGP.22 is the GSMA consumer eSIM standard. A Local Profile Assistant (LPA) pulls a profile onto the device, usually triggered by a person scanning a QR code or tapping through an app. Latest versions: v2.7 (April 2026) and v3.1.
• SGP.32 is the GSMA IoT eSIM standard. A server-side eSIM IoT Remote Manager (eIM) pushes instructions to an IoT Profile Assistant (IPA) on the device or on the eUICC. No human in the loop. Latest version: v1.3 (May 2026), with certification currently tracking v1.2.
• What they share: both download profiles from the same kind of profile server, the SM-DP+, so operators do not need a second provisioning back end.
• What they don’t share: the eUICC operating system. An SGP.22 eUICC cannot be turned into an SGP.32 one over the air.
• The floLIVE lesson: before SGP.32, the practical answer for global IoT was to work around remote provisioning entirely (multi-IMSI). Under SGP.32, that workaround does not disappear; it becomes the bootstrap layer underneath the standard.

Why floLIVE makes a useful lens

floLIVE is not a SIM vendor or a mobile operator in the traditional sense. It describes itself as owning the full connectivity stack: its own cloud-native core network, connectivity management platform (CMP), SIM technology and policy engines, with local points of presence around the world for in-country breakout. That full-stack position matters here, because it means the company has had to make a decision at every layer that SGP.22 and SGP.32 touch.

The business dates from the mid-2010s. Around the turn of 2020 it combined with BD Innovations, an Israeli connectivity software company founded in 2009, and raised a $21.5 million round led by 83North with Dell Technologies Capital, Saban Ventures and Qualcomm Ventures. A $15.5 million Series B led by Intel Capital followed in July 2021, and a $47 million Series C in September 2023, taking total funding to roughly $86 to 88 million depending on whose tally you read. Ericsson also used some of floLIVE’s technology in its own IoT business before selling that unit to Aeris at the end of 2022.

In other words: a well-funded, chipset-adjacent, global IoT connectivity specialist that has been through every phase of the eSIM debate. If any provider’s history explains why SGP.32 exists, it is one like this.

The past: engineering around the standards (2015 to 2022)

When floLIVE started, an IoT company that wanted to ship one device worldwide had two GSMA options, and neither fitted.

SGP.02, the original M2M standard, was server-driven but operator-controlled. Profile management relied on an SM-SR tied to the operator relationship, activation leaned on binary SMS, and changing operator meant a bilateral integration project. floLIVE’s own SGP.32 material still describes it as heavy and operator-locked, which is a polite way of putting it.

SGP.22, the consumer standard, arrived in 2016 (SGP.22 v2.0 was published in October 2016, building on the SGP.21 architecture first issued in December 2015). It was lighter and opened the door to genuine multi-sourcing, but every profile change assumed a user on the device. For a meter in a cabinet or a tracker on a trailer, that assumption is simply wrong. The industry’s workarounds were QR codes on stickers, companion apps pretending to be a human, and factory bootstrap profiles with a prayer.

floLIVE’s answer was to sidestep remote SIM provisioning almost entirely. Its core product became multi-IMSI over eUICC: a SIM applet that holds several network identities (IMSIs) inside a single profile and switches between them autonomously, combined with its own core network so that traffic could break out locally in each country. The device never downloads anything. The SIM just changes which identity it presents. For a decade that was arguably the most practical way to get “one SKU, every network” behaviour, and floLIVE built its business on it.

SGP.22 did not vanish from the picture. floLIVE has also marketed a consumer eSIM offering to operators and IoT MVNOs, hosting a library of local SGP.22 profiles managed through its CMP. That is SGP.22 used where it actually belongs: devices with a screen, a user or an IT department behind them.

SGP.22 vs SGP.32: the technical differences that matter

Before the present-day story, it is worth being precise about what actually changed between the two specifications, because a lot of vendor material blurs it.

Two points get lost in most comparisons. First, the reuse of the SM-DP+ was deliberate: operators that already serve consumer eSIM can serve IoT without building a new provisioning estate. Second, SGP.32 does not make SGP.22 obsolete. It makes SGP.22 the wrong default for headless devices, which is a different thing.

The present: floLIVE on SGP.32 (2026)

On 19 February 2026, floLIVE announced operational SGP.32 support across its network through its partnership with Kigen. The architecture is worth reading closely, because it shows how a provider with a pre-SGP.32 business model adapts to the standard rather than being replaced by it.

• Kigen supplies the standard layer: its SAS-certified eIM and its eSIM operating system on eSA-certified eUICCs.
• In-factory profile provisioning: using Kigen’s IFPP capability, eUICCs leave the factory already loaded with a floLIVE profile, so the device connects on first power-up anywhere.
• Multi-IMSI as the bootstrap: that factory profile is floLIVE’s multi-IMSI applet, which the company says can hold up to ten IMSIs and switch between them autonomously. Local operator profiles are then pulled down over SGP.32 when a market requires them.
• Hybrid fallback: if a downloaded local profile or its network fails, the multi-IMSI layer is there to keep the device reachable.
• Aggregation: customers can run natively on floLIVE’s network or keep their existing providers and manage everything through its CMP Aggregator, which is pitched at retaining visibility when a device switches operator.

Kigen’s head of global sales described SGP.32 at launch as “the missing operations layer for connectivity state”, which is a fair summary of the gap floLIVE spent a decade filling with proprietary technology. floLIVE’s own product lead was notably candid at the same launch, pointing out that SGP.32 leaves network complexity, back-end integration, compliance, cost control and multi-operator management as unsolved problems. Unsurprisingly, he positioned the company’s platform as the answer to those.

The interesting strategic move is where floLIVE has put its moat. Under SGP.02 and SGP.22, multi-IMSI was the product. Under SGP.32, the standard handles operator switching, so multi-IMSI becomes the bootstrap: the thing that gets a device online before any profile download and keeps it online if one fails. The company’s own solution brief for operators is even titled around turning SGP.32 from a threat into an opportunity. That framing tells you SGP.32 genuinely changes the economics for anyone whose value used to be “we make switching operators possible”.

The future: where SGP.22 and SGP.32 go from here

SGP.22 stays, in its lane. Phones, tablets, laptops, wearables and IT-managed devices will keep using consumer eSIM, and the GSMA is still actively maintaining it (v2.7 arrived in April 2026). For IoT devices with a real user interface or an MDM platform behind them, SGP.22 remains a perfectly sound choice, and router vendors have shown it can be wrapped in cloud tooling to good effect.

SGP.32 becomes the default for new headless hardware. Kigen and floLIVE both expected adoption to ramp through 2026, with controlled pilots preceding mass rollouts. Specification maturity is moving too: v1.3 landed in May 2026, while the SGP.33 test suites still certify against v1.2, so expect a period where “SGP.32 certified” and “latest SGP.32” are not the same claim.

The bootstrap becomes the battleground. floLIVE’s design shows the pattern. Once the standard handles profile download, providers compete on what is in the eUICC at the factory, how good its coverage is before any local profile arrives, and what catches the device when something fails. The GSMA formalising in-factory provisioning in SGP.41 (February 2025) points the same way.

Mixed estates are the reality for years. Devices already in the field on SGP.02 or SGP.22 cannot be converted over the air, so most fleets will run two or three management models side by side through a long refresh cycle. That is where platform portability, and the question of who controls the eIM, start to matter more than any single feature.

What to ask any provider, floLIVE included

1. Is the eUICC natively SGP.32, and which version is it certified against?
2. Where does the IPA live: in the device firmware (IPAd) or on the eUICC (IPAe)?
3. Who operates the eIM, and can I move my fleet to a different eIM if I change provider?
4. What is the bootstrap profile, which networks does it reach in my target markets, and what are its commercial terms once local profiles take over?
5. What happens if a downloaded local profile fails: is there a fallback, and is it automatic?
6. Can the platform manage my existing SGP.02 or SGP.22 devices alongside SGP.32 ones?
7. Can I trial factory provisioning and remote switching on my own hardware before committing at scale?

A good provider will answer all seven without changing the subject. floLIVE’s published material covers most of them directly, which is more than many manage.

Frequently asked questions

What is the main difference between SGP.32 and SGP.22?

SGP.22 is built for consumer devices, where a user triggers profile downloads through a Local Profile Assistant. SGP.32 is built for IoT, where a server-side eIM manages profiles across whole fleets with no user involved. Both use the SM-DP+ to deliver profiles.

Can an SGP.22 eUICC be upgraded to SGP.32?

No. The specification is part of the eUICC operating system, which is fixed at manufacture. Moving to SGP.32 means new hardware or, where the device has a SIM slot, a removable SGP.32 card with the IPA on the card.

Does floLIVE support SGP.32?

Yes. floLIVE launched operational SGP.32 support in February 2026 in partnership with Kigen, using Kigen’s certified eIM and eUICCs, with floLIVE’s multi-IMSI profile pre-loaded at the factory as the bootstrap.

What is the latest version of SGP.32?

The GSMA published SGP.32 v1.3 in May 2026, alongside SGP.31 v1.3. The current test specifications (SGP.33 v1.2) apply to SGP.32 v1.2, so certified products today generally reference v1.2.

Is multi-IMSI the same as eSIM?

No. Multi-IMSI switches between several network identities held inside one SIM profile, with no profile download. eSIM remote provisioning (SGP.22 or SGP.32) downloads and swaps whole operator profiles. Under SGP.32 the two can work together, with multi-IMSI acting as the bootstrap or fallback layer.

Is SGP.22 still worth using for IoT?

For devices with a user interface or a device-management platform behind them, often yes. For headless, low-power or long-life devices, SGP.32 is the better default for new designs.

euicc.co.uk is independent and has no commercial relationship with floLIVE or Kigen. Company details are drawn from public announcements and floLIVE’s own published material.

Related reading

• SGP.32 explained: eIM, IPA and eUICC
• SGP.22 vs SGP.32: the quick comparison
• Future-proof IoT eSIM: what the eUICC can and can’t protect
• IoT eSIM in Norway: the eUICC and SGP.32 guide
• How to choose a bootstrap provider (sgp32.co.uk)
• Where SGP.32 moves lock-in (sgp32.co.uk)
• IPAe vs IPAd explained (sgp32.co.uk)
• eSIM IoT Manager: the eIM explained

Sources

• GSMA eSIM consumer and IoT specifications register
• IoT Now: floLIVE launches full support for SGP.32 (February 2026)
• floLIVE: SGP.32 for IoT
• Globes: floLIVE raises $15.5m (July 2021)