floLIVE and SGP.32: The Lock in the Data Path

Most SGP.32 stories are about identity. Which operator profile sits on the eUICC, who is allowed to swap it, and how you avoid getting stuck with the SIM you shipped. All good questions. But there is another one that hardly anybody asks, and I think it matters just as much: once the right profile is live, where do the packets actually go?

floLIVE is the vendor that has built its whole business around that second question. It is a London-headquartered company with its engineering in Israel, and for the best part of a decade it has been building a distributed mobile core whose job is to stop IoT traffic doing pointless laps of Europe. In February 2026 it added full SGP.32 support through Kigen. That makes it a useful case study, because floLIVE shows more clearly than anyone that a standards-compliant eSIM and a sensibly routed IoT service are two different things, and you need both.

floLIVE SGP.32 at a glance

SGP.32 decides which profile. It does not decide where the packets go.

Let me start with what the standard does, because it frames everything floLIVE sells. SGP.32 is the GSMA’s eSIM IoT specification. An eIM in the cloud instructs an IoT Profile Assistant on the device to download, enable, disable or delete operator profiles held on the eUICC, and an SM-DP+ prepares and delivers those profiles. The architecture pillar goes through it properly.

What SGP.32 does not do is route traffic. Once a profile is enabled, the data session is anchored wherever that profile’s operator anchors it. If the profile belongs to a home network in another country, or to a provider whose packet gateway sits in Frankfurt, that is where your data goes, however compliant your eSIM is.

I wrote about this from the UK buyer’s side on IoT Portal in where does your IoT SIM data actually go? The short version: a UK device on a UK mast talking to a UK cloud can still have its data leave the country and come back, simply because of where the SIM provider’s gateway is. SGP.32 does not change that. The provider’s core does.

That is floLIVE’s patch. It is not primarily an eSIM company. It is a core network company that happens to care a great deal about SIMs.

The floLIVE story: from London start-up to distributed core

The start-up years: an IoT network in the cloud

floLIVE started life in London in the middle of the last decade, and the founding year depends on which source you read: some say 2015, the company’s own brief says 2016. When it raised a $4.2m Series A in February 2017, from ARIE Capital and Golden Sunflower Capital, it was pitching end-to-end IoT networking: device management, IoT applications, analytics, and core networks run in the cloud and built for IoT. It already had a scattering of offices in London, Paris, Limassol, Hyderabad and Tel Aviv, and was setting up in California.

Notice the phrase “core networks run in the cloud”. In 2017 that was unusual. Most IoT connectivity was still resold operator SIMs with a portal bolted on top. floLIVE’s bet from day one was that IoT needed its own core, not a borrowed consumer one.

2020: an AT&T man and an Israeli merger

The company’s second phase started in February 2020, when it raised $21.5m led by 83North, with Dell Technologies Capital, Saban Ventures and Qualcomm Ventures alongside, and appointed Nir Shalom as CEO. Shalom had run AT&T Israel and AT&T’s network application development, so this was a telco operator’s hire, not a start-up founder’s.

Three months later floLIVE merged with BD Innovations, an Israeli company that built business support software for telecoms and infrastructure firms, in a stock-for-stock deal. BD Innovations became floLIVE’s R&D centre and Israeli branch, management stayed in the UK, and the combined business had about 90 people across Bnei Brak, London, Sofia, Hong Kong and Dallas. BD’s CEO said at the time that the funding round would not have happened without the merger, which tells you the investors were buying the combined engineering capability, not just the London brand.

2021: Intel, private 5G and the cloud bet

In July 2021 Intel Capital led a $15.5m extension, taking that round to $37m, with Qualcomm Ventures, Dell Technologies Capital, 83North, Saban and ARIE all following on. The pitch at the time leaned heavily on private 5G: floLIVE’s core could run on a private radio network for a campus, or connect to public operator networks for national deployments. The money was earmarked for upgrading the global network to 5G and a “SIM to cloud” offering with a major cloud provider. Intel later sold its stake, but the cloud partnership with AWS became part of the story.

2022: iSIM, satellite and an Ericsson footnote

In January 2022 floLIVE, Kigen and Sony Semiconductor Israel announced a cellular IoT product combining Sony’s ALT1250 chipset, Kigen’s iSIM OS, and floLIVE’s global connectivity and over-the-air multi-IMSI. Later that year it partnered with Skylo to extend coverage into rural areas over satellite NTN.

There is also an Ericsson footnote worth knowing. Ericsson used some floLIVE technology in its own IoT business. When Ericsson sold that loss-making unit to Aeris, a more direct competitor of floLIVE, the relationship ended. floLIVE’s CEO later said it no longer worked with the former Ericsson business, but that old Ericsson customers were showing interest in floLIVE.

2023: $47m and the Turkey proof point

In September 2023 floLIVE raised a $47m Series C led by Greenfield Partners and 83North, with Qualcomm Ventures, Dell Technologies Capital, Saban Ventures and Hazelnut Partners. Shalom used the launch to make his core argument loudly. He estimated that roaming accounts for around 98% of IoT connectivity, and that roaming can add 120 ms or more of latency, which is too much for some services.

A month later came the proof point I think is most relevant to SGP.32 readers. floLIVE, Kigen and Protahub announced local IoT connectivity in Turkey, a market where permanent roaming is not possible and IP data has to be routed in-country. I come back to this below, because it is a perfect miniature of the whole localisation problem.

2025: Local Breakout as a product

In February 2025 floLIVE launched its Local Breakout service for MNOs and MVNOs, selling the breakout capability itself rather than only using it inside its own SIM offer. It now pitches packet gateways that can sit in public cloud regions, in a customer’s own data centre or on premises, and lists a packet-gateway-as-a-service on the AWS Marketplace.

2026: SGP.32, A Network Beyond and satellite in Brazil

On 19 February 2026 floLIVE announced full operational support for SGP.32 with Kigen. Days later it took “A Network Beyond”, its umbrella for AI-assisted network operations, to MWC in Barcelona. In May it won an IoThinkTank infrastructure award for that platform, and in October it launched combined cellular and Skylo satellite connectivity in Brazil with local partners iuh! Digital and NLT.

Why floLIVE exists

Strip away the branding and floLIVE exists because of one structural problem: classic IoT connectivity is roaming connectivity, and roaming was designed for people on holiday, not for meters bolted to walls for fifteen years.

Roaming creates three headaches for IoT, and floLIVE’s product line maps neatly onto them.

• Regulation. More and more countries restrict permanent roaming or require data to stay in-country. A roaming SIM that worked fine at launch can become non-compliant without anyone touching it.
• Routing. Home-routed roaming hauls traffic back to the SIM’s home network, adding latency and dragging data through countries it has no reason to visit.
• Control. When you rely on a stack of roaming agreements, you have little visibility of what is happening in the network, and little ability to change it.

floLIVE’s answer was to build its own cloud-native core, integrate it with many radio partners, give the SIM several local identities through multi-IMSI, and place packet gateways near the devices. SGP.32 is the newest tool in that kit, not the foundation of it.

What drove floLIVE, and the honest counterpoint

Here is what I think got floLIVE this far:

• It owns the core. Most IoT connectivity firms resell. floLIVE runs the network functions itself, which is why it can sell breakout, steering and policy as products.
• It started cloud-native. It was building cores on cloud infrastructure before that was fashionable, which made placing gateways in new regions a deployment job rather than a hardware project.
• Multi-IMSI as a practical bridge. Its patented applet gave customers localisation without waiting years for eSIM standards to mature.
• Patient, strategic investors. Qualcomm, Dell and 83North have stayed through several rounds.

The honest counterpoint

I would not be doing my job if I left it there. A few things are worth keeping in view.

First, floLIVE’s network numbers move around. Within one year its own releases have said “over 40” and “over 70” local points of presence, and a trade profile cited 70 packet gateways across 23 hubs. These may all be true descriptions of different things, but if you are buying on gateway location, ask for the specific list.

Second, the SGP.32 eIM is Kigen’s, not floLIVE’s. That is a perfectly sensible choice, since Kigen’s eIM is SAS-certified and Kigen is one of the most credible names in the space. But it means floLIVE’s SGP.32 story is an integration story, and the eIM layer has its own lock-in questions, which I cover in the Kigen profile.

Third, floLIVE is a scale-up competing with giants. Vodafone, Wireless Logic, Eseye and the big operator groups all have larger customer bases. floLIVE’s advantage is architecture, and architecture only wins if buyers know to ask about it.

What SGP.32 provides, and what floLIVE adds

The pattern is the same one I saw with Eseye: SGP.32 is a narrow, valuable standard, and the vendors worth talking to are the ones who are clear about everything around it. Where Eseye’s centre of gravity is orchestration, floLIVE’s is the network.

Is floLIVE an eIM provider?

No, and it does not claim to be. floLIVE’s SGP.32 launch was explicitly built on Kigen’s eIM, Kigen’s secure eSIM OS, and Kigen’s in-factory profile provisioning, with floLIVE providing the bootstrap profile, the connectivity, and the management platform on top.

It does matter for buyers, because it tells you where to look for each kind of dependency. If you want to know about eIM portability, the questions go to Kigen as much as to floLIVE. If you want to know about routing, breakout and steering, the questions go squarely to floLIVE.

Multi-IMSI as the bootstrap

This is the clever bit, and the part I think gets overlooked. Every SGP.32 device needs a bootstrap profile, something to connect with on first power-up so it can reach the eIM and download the profile it really needs. I have written about the bootstrap problem before, because a weak bootstrap turns elegant provisioning diagrams into truck rolls.

floLIVE’s answer is to make the bootstrap its multi-IMSI applet. Kigen’s in-factory provisioning loads it onto the eUICC before the device ships. On first power-up the device can connect using whichever of up to ten identities works locally, reach the eIM, and pull down a local operator profile over SGP.32. If that local profile later fails, the multi-IMSI profile is still there as a fallback.

That is a hybrid model, and floLIVE sells it as one. Customers can run pure SGP.32, multi-IMSI over eSIM, or both together. I think the hybrid is the honest answer for most fleets, and the analysts agree: a Transforma Insights report published by floLIVE argued that enterprises should not try to assemble SGP.32 themselves, and that an eSIM with a multi-IMSI first profile combines coverage and cost efficiency with compliance and flexibility. That report was paid for by floLIVE, so weigh it accordingly, but the argument stands up on its own.

It is also, of course, a lock. Whoever owns the bootstrap has a very strong position, because every device in the field depends on it to recover. More on that below.

The data path: why breakout still matters after SGP.32

Here is the argument I would make to any SGP.32 buyer, and it is the one floLIVE is best placed to illustrate.

Localising a device onto a local profile is meant to solve permanent roaming and data residency. But a local profile only keeps data local if that profile’s traffic breaks out locally. And a lot of IoT connectivity does not use a local profile at all: it uses a global or multi-IMSI profile, where the routing is entirely down to the provider’s core.

So there are really two routes to keeping data in a country:

1. Download a local operator profile, and rely on that operator’s in-country core.
2. Keep a global or multi-IMSI profile, and rely on the provider placing a packet gateway in that country.

SGP.32 only helps with the first. floLIVE sells both, and in many deployments the second is simpler, cheaper and quicker to change. Shalom’s own framing at the 2023 raise was that roaming adds latency and complexity most customers never see. With gateways in many locations, floLIVE can cut that detour without a profile swap at all.

For UK readers there is a practical sting in this. If your devices sit in the UK and your application is in the UK, the question to ask any provider, floLIVE included, is whether there is a UK gateway in the mesh and whether your traffic is pinned to it. The IoT Portal piece on IoT SIM data sovereignty has the full question list, and an interactive explainer of what happens when that gateway fails.

Turkey: the whole problem in one country

If you want one example that shows why SGP.32 alone is not enough, look at what floLIVE did in Turkey in October 2023.

Turkey does not allow permanent roaming, and it requires IP data to be routed locally, in-country. Its rules also differ from standard eUICC profile management: a Turkish company, Protahub, is described as the only local entity authorised to control local eSIM subscription profiles, and it runs its own SM-SR. Before the partnership, global customers had to contract directly with local operators, use separate APIs, and accept limited control.

The solution needed three parties. floLIVE’s platform detects a device arriving in Turkey and triggers the local profile download. Kigen’s remote SIM provisioning platform takes part in an SM-SR swap. Protahub’s own SM-SR performs the download and validates the result with both. The customer gets one global SKU, and the device ends up legally connected, with data routed in Turkey.

That was SGP.02-era plumbing, not SGP.32, but the shape of the problem has not changed. A standard can deliver a profile. It cannot sign a Turkish regulator’s paperwork, find the only authorised local partner, or make sure the data stays in the country. Those are exactly the parts floLIVE built its business around.

Where the lock lives

In the conservation of lock-in editorial I argued that SGP.32 does not remove operator lock-in, it moves it to four stickier places: the eIM control plane, the eUICC OS, the bootstrap profile, and the managed service. floLIVE touches one of those directly, and adds one I did not list.

The bootstrap. floLIVE’s multi-IMSI applet is loaded at the factory and is what every device falls back on. If you ever want to move away from floLIVE, the bootstrap is the thing you need a plan for. Ask whether it can be replaced over the air, by whom, and at what cost.

The data path. This is the one I would add to the list. If floLIVE’s packet gateways are where your traffic breaks out, then your IP addressing, firewall rules, private APN, VPN termination and possibly your compliance documentation are all built around floLIVE’s core. Changing eSIM profile is a software operation. Changing the path your data takes, and re-documenting it for your DPIA, is a project.

That is not a criticism. Every serious IoT connectivity provider creates some dependency, and floLIVE’s is arguably the most useful kind, because it buys you routing control most providers cannot offer. But it is a lock, and the UK SGP.32 landscape makes more sense once you add it.

floLIVE’s role in the future landscape

I think floLIVE is well placed for where this market is going, for three reasons.

First, data sovereignty is getting stricter, not looser. Brazil, Turkey, Saudi Arabia, India and others have already tightened rules on permanent roaming or data location, and Europe’s conversation about sovereignty keeps getting louder. Every one of those rules is ultimately about where the packet gateway is, and that is floLIVE’s home ground.

Second, SGP.32 commoditises the identity layer. As more eUICCs, eIMs and SM-DP+ platforms become certified and interchangeable, value moves to whatever SGP.32 leaves out: contracts, coverage, routing and operations. floLIVE’s strengths are concentrated there.

Third, the hybrid model is winning. The market has largely stopped arguing about multi-IMSI versus eSIM and started combining them. floLIVE was doing hybrid before it was fashionable.

The risks are just as clear. The big aggregators, Wireless Logic above all, are buying their way to scale and building their own distributed cores. Operators are getting better at local breakout themselves. And floLIVE’s own messaging has drifted towards AI-assisted network operations, which is interesting but harder for a buyer to verify than “here is your gateway list”. My hunch is that floLIVE’s best future is as the routing and breakout layer that other people’s SGP.32 stacks plug into, which is exactly what its partner and marketplace offers suggest it is aiming for.

Questions to put to floLIVE, or anyone selling SGP.32

• Which eIM do you use, who operates it, and can I move my devices to another eIM?
• What is the bootstrap profile, who owns it, and can it be replaced over the air?
• When my device is in the UK, in which country does its traffic break out, and is there a UK gateway?
• Will you commit to the breakout location contractually?
• If the local gateway fails, does traffic fail over to another country or fail closed?
• Which countries do you support with local profiles, and which only with roaming or multi-IMSI?
• How do your network figures break down: how many packet gateways, in how many locations, in which countries?
• Where are the CMP, subscriber data, logs and support staff located?
• How are profile downloads and SGP.32 switching priced, compared with multi-IMSI?
• If I leave, what can I export, and what stops working?

There is a longer generic list in what to ask your eSIM provider.

floLIVE SGP.32 FAQ

Who founded floLIVE?

floLIVE was founded in London in the mid-2010s; sources differ between 2015 and 2016. Rony Cohen is listed by the company as a co-founder, and Percy Grundy was named as co-founder and co-CEO when it raised its Series A in 2017. In 2020 it merged with Israeli company BD Innovations, which became its R&D centre.

Who runs floLIVE now?

Nir Shalom has been CEO since February 2020. He previously ran AT&T Israel.

Where is floLIVE based?

Its headquarters are in London, with R&D and an innovation centre in Israel and offices in other regions.

Does floLIVE support SGP.32?

Yes. On 19 February 2026 it announced full operational SGP.32 support through its partnership with Kigen, with customers able to run pure SGP.32 or hybrid deployments that combine SGP.32 with multi-IMSI.

Is floLIVE an eIM?

No. Its SGP.32 service uses Kigen’s SAS-certified eIM. floLIVE provides the connectivity, the bootstrap profile and the management platform.

What is multi-IMSI over eSIM?

It is floLIVE’s patented SIM applet that holds up to ten network identities and switches between them without downloading a new profile. In its SGP.32 offer it is used as the factory-loaded bootstrap and as a fallback.

What is floLIVE Local Breakout?

It is floLIVE’s service for placing packet gateways close to devices, so traffic leaves the mobile network locally or regionally instead of being routed back to a home network. Gateways can run in public cloud, a customer’s data centre or on premises.

Does SGP.32 keep my IoT data in the UK?

Not on its own. SGP.32 manages which profile is active. Where traffic breaks out depends on the profile’s operator or the provider’s packet gateways. You need to ask about routing separately.

Can I keep my existing SIM providers with floLIVE?

floLIVE says its CMP Aggregator can manage devices on other providers’ connectivity alongside its own. As with any aggregator, check what visibility and control you actually get over the other providers’ SIMs.

Further reading and sources

Within the cluster: the UK SGP.32 landscape, the other vendor profiles for Eseye, Kigen, 1GLOBAL, Wireless Logic and Onomondo, and the SGP.32 v1.2 specification explainer. On euicc.co.uk, SGP.32 vs SGP.22 through floLIVE’s journey. On IoT Portal, where does your IoT SIM data actually go?

Company history: Series A, Tech.eu, 2017; $21.5m round and new CEO, Calcalist, 2020; BD Innovations merger, Calcalist, 2020; Intel Capital investment, NoCamels, 2021; iSIM with Kigen and Sony, eeNews Europe, 2022; Skylo partnership, 2022; $47m Series C, TechCrunch, 2023; floLIVE, Kigen and Protahub in Turkey, 2023; floLIVE management team.

SGP.32 and network: floLIVE launches SGP.32 support, IoT Now, February 2026; floLIVE SGP.32 for IoT; floLIVE Local Breakout; Local Breakout service launch, IoT M2M Council, 2025; RCR Wireless analyst angle, 2026; A Network Beyond at MWC 2026; IoThinkTank award, 2026; Skylo and Brazil, October 2026; Transforma Insights report for floLIVE on SGP.32.