IoT eSIM: Providers, SGP.32, Public IP & Private IP Guide

What is an IoT eSIM?

An IoT eSIM is a programmable SIM technology designed to give cellular connectivity to Internet of Things devices without permanently tying the device to a single mobile network profile. That simple description hides a substantial change in the way businesses can buy, deploy and manage cellular connectivity.

Traditional IoT deployments have been built around physical SIM cards supplied by a mobile operator or connectivity provider. If the connectivity agreement changes, the SIM often has to change too. For ten devices in accessible locations, that is an inconvenience. For 10,000 smart meters, security systems, EV chargers, agricultural gateways or industrial controllers spread across several countries, replacing SIM cards becomes a serious operational problem.

IoT eSIM changes the equation. Instead of treating the network subscription as something permanently attached to the SIM installed during manufacture or deployment, a compatible eSIM can support remote management of network profiles. That opens up remote profile provisioning, changing providers without replacing hardware, deploying one hardware SKU into multiple countries, better resilience, fewer engineer visits, and centralised management of large estates. For a plainer side-by-side, see our guide to IoT eSIM versus the plastic SIM.

The requirements that actually decide the contract

Before choosing a provider, work through the questions below. The last one matters more than most buyers realise, because the real promise of IoT eSIM is control over the connectivity lifecycle of a device, not simply the removal of a plastic card.

IoT eSIM, eUICC, embedded SIM and iSIM: the difference

The terminology around eSIM is unnecessarily confusing, and providers use it loosely. Two products both advertised as IoT eSIMs can offer very different capabilities. Here is what the terms actually mean.

SIM

The traditional Subscriber Identity Module stores the credentials a device uses to authenticate with a network. In industrial equipment this is commonly a removable 2FF, 3FF or 4FF card.

eSIM

eSIM generally refers to technology that lets network subscription profiles be managed electronically rather than by physically replacing an operator-specific SIM. Commercially the term is used very loosely, which is why the standard beneath it matters.

eUICC

An eUICC, or embedded Universal Integrated Circuit Card, is the secure environment able to store and manage SIM profiles. This is the technology that makes remote provisioning possible. Crucially, eUICC does not mean physically embedded. An eUICC can exist in a removable SIM form factor, so you can have what looks like an ordinary plastic SIM that supports eSIM functionality, which is useful when testing in existing equipment. The eUICC explained in more depth sits at the centre of the whole ecosystem.

MFF2

MFF2 is a soldered SIM form factor common in industrial hardware. The component is soldered directly onto the PCB rather than inserted into a holder, which improves resistance to vibration, moisture, corrosion and tampering.

iSIM

An integrated SIM, or iSIM, takes integration further by building SIM functionality into the device silicon rather than using a separate component. For very compact or high-volume products, iSIM could become significant. For most organisations buying routers and gateways today, the procurement discussion is more likely to be about physical SIM, eUICC and SGP.32.

How does IoT eSIM work?

A traditional deployment runs device to SIM to mobile network to application, with the SIM holding credentials tied to the connectivity service. Remote SIM provisioning introduces another layer: the eUICC can securely receive and manage network subscription profiles, so the network identity a device uses does not have to stay the same for its whole operational life.

This separates two things that historically became tightly coupled: the physical device and its network subscription. For manufacturers expecting products to run for five, ten or fifteen years, that distinction matters enormously.

What is SGP.32, and why it matters in 2026

SGP.32 is the GSMA technical specification for the newer IoT eSIM architecture. It was created to address requirements that are awkward in consumer eSIM and earlier machine-to-machine designs. An IoT device is not a smartphone. It may sit inside a CCTV cabinet, under a solar panel, on a wind turbine, in a vending machine or inside an EV charger, with no screen, no keyboard and constrained connectivity, somewhere nobody wants to visit for a decade. SGP.32 introduces an architecture built for remote provisioning and management of eUICCs in exactly those network-constrained and interface-constrained devices, including a server component, the eSIM IoT remote Manager or eIM, that can initiate profile changes remotely rather than waiting for a person to tap a screen.

The significance is not that eSIM suddenly exists. It existed long before SGP.32. The significance is a standardised architecture suited to large-scale IoT, which makes it easier for manufacturers and enterprises to avoid designing an entire product lifecycle around one provider.

In 2026 SGP.32 has moved from something on a roadmap to something shipping. Certified hardware, commercial SIM deliveries and orchestration platforms are all now generally available. For a fuller picture of who is shipping what, read our coverage of where UK and European IoT eSIM actually stands in mid-2026 and the emerging multi-carrier control layer being built above SGP.32. For the architecture-versus-implementation split, our sister reference covers how SGP.31 relates to SGP.32.

Do not settle for “yes, we support SGP.32”. Ask which version is implemented, which components have been certified or tested, and whether you can provision profiles from third-party SM-DP+ environments. That is a far more useful question.

Is every IoT eSIM SGP.32?

No, and this is one of the biggest sources of confusion when comparing providers. The phrase IoT eSIM is used to describe several technologies: SGP.32, earlier M2M eSIM, consumer-style eSIM adapted for IoT, eUICC with provider-controlled profile switching, multi-IMSI connectivity, roaming SIM technology marketed alongside eSIM, proprietary network switching, or combinations of these. Some are perfectly good solutions. The mistake is assuming they are interchangeable.

If the objective is “reliable multi-network connectivity for 200 UK CCTV routers”, a managed multi-network IoT SIM may solve the problem extremely well. If the objective is “we manufacture 100,000 devices a year and want control over which operator profiles they use across a ten-year global lifecycle”, SGP.32 becomes strategically important. Start with the problem, not the acronym.

What is the best IoT eSIM provider?

There is no single best IoT eSIM provider, and any site claiming otherwise without knowing your application is oversimplifying. The right connectivity for a CCTV installation can be completely wrong for a battery-powered environmental sensor. The cheapest tariff is not necessarily the cheapest solution either. If Provider A charges a pound less per SIM per month but Provider B eliminates two engineer visits across a ten-year life, Provider B is very likely the lower total cost.

The right question is which architecture and provider best match the operational, technical and commercial requirements of the deployment. When you compare providers, do not start at price per gigabyte. Start with architecture:

• Coverage: which networks are actually available at each site. “Global coverage” can mean one usable network in a market that matters to you.
• Multi-network behaviour: how network selection works, whether roaming is steered, whether the modem can select manually, and what happens after a registration failure.
• Profile ownership: who controls the profiles, whether another provider’s profile can be downloaded, and whether you can migrate away. Technical portability and commercial portability are not the same thing.
• Management platform and API: activation, suspension, usage monitoring, alerts, caps, reporting, permissions and audit logs. For large fleets the API can matter more than the portal.
• Support: hours, escalation, network troubleshooting and service levels. When 3,000 devices go quiet, a cheap tariff suddenly looks far less important.

Our practical UK cellular IoT connectivity guide works through provider selection in more detail.

Public IP, private IP and private APN eSIM

One of the most important requirements is IP addressing, and it is where a lot of eSIM buyers actually start, because they need to reach equipment remotely. A standard mobile connection usually sits behind CGNAT, Carrier Grade Network Address Translation, so the device does not get a directly reachable public IPv4 address. For outbound internet access that is fine. For inbound connections it is a problem.

A public static IP eSIM keeps the internet-facing address fixed, which suits firewall whitelisting, remote router administration, inbound VPN, CCTV access and source-IP authentication. A public dynamic IP can still give genuine inbound connectivity, but the address can change, so dynamic DNS may be needed and strict IP-based rules may not suit it. A private IP architecture keeps devices off the public internet entirely, giving each device a private address reachable only through controlled private networking, which can be combined with private APNs, IPsec VPNs, MPLS or central VPN concentrators. For industrial, infrastructure and security applications this is often the better model.

Public IP is not automatically better. It is one architecture among several, and the right answer depends on the network design.

IoT eSIM for Teltonika routers

“eSIM for Teltonika” and “Teltonika eSIM” are common searches, and there are really two questions inside them. Can a Teltonika router use an IoT eSIM? Potentially yes, depending on the specific router, modem and eSIM implementation. For existing equipment with conventional SIM slots, a removable eUICC product can provide a route into eSIM-style services without needing a soldered MFF2 component, while newer hardware platforms may offer more integrated options. Do not assume that inserting something labelled an eSIM automatically gives the router full SGP.32 functionality. Compatibility needs to be confirmed across the router, modem, firmware, eUICC, provisioning architecture and connectivity provider.

Industrial routers are strong candidates for remotely manageable connectivity precisely because they are so often installed somewhere inconvenient: CCTV towers, roadside cabinets, wind and solar farms, EV chargers, ANPR sites, construction sites and remote offices. If the provider needs changing, sending an engineer purely to swap a SIM is expensive, and remote profile management can remove that requirement. For a worked example of the router side of this, see our Teltonika RUT956 guide.

IoT eSIM by application

Different deployments should prioritise different things. The connectivity that suits a CCTV tower is wrong for an alarm panel, and both differ from a fleet of asset trackers. The table sets out what to weigh for the most common business cases.

CCTV and security

CCTV is unusual because its data profile is heavy. A sensor might send 20MB a month while a CCTV system consumes hundreds of gigabytes, so establish expected consumption, whether video is streamed continuously or stored locally, remote viewing frequency, upload resolution, camera count, public IP and VPN needs, available networks per site and failover before choosing. For temporary towers and rapidly deployed systems, multi-network capability is particularly useful, because the best network at one site might be EE and at the next it could be VodafoneThree, O2 or Three. Alarm and security systems tend to have the opposite profile: little data, but availability matters enormously, so prioritise multi-network access, resilience, rapid recovery and secure private connectivity over cost per gigabyte.

Retail, vending and kiosks

Retail estates involve large numbers of distributed devices: payment terminals, kiosks, vending machines, digital signage, refrigeration monitoring, footfall sensors, smart lockers and backup broadband routers. This is exactly where centralised management, pooled data and an API earn their place, and where a single hardware build provisioned on arrival beats holding country-specific SIM stock. For unattended equipment the economics are stark: if a SIM costs a pound fifty a month but an engineer visit costs a hundred and fifty, avoiding one unnecessary visit funds years of connectivity.

Agriculture

Agricultural IoT is a coverage problem first. The nearest mast is not necessarily on the network the farmer’s phone uses, so a multi-network service is valuable for irrigation controllers, livestock monitoring, weather stations, grain-store monitoring and remote pumps. Network diversity is not an excuse to ignore RF engineering, though. A clever eSIM cannot fix a badly installed antenna, so consider antenna positioning and gain, cable losses, bands and router placement as well.

EV charging, energy and utilities

Charge points need connectivity for payment, OCPP, remote monitoring, firmware updates and load balancing, and they stay deployed for years, which creates real risk in permanently coupling the equipment to the connectivity agreement signed at manufacture. Smart meters, solar and battery storage, substation monitoring and remote telemetry combine long life, remote locations and expensive engineer visits, which makes them natural eSIM candidates. For these, procurement should consider not just next year but the next decade: whether the current network, roaming agreement, provider terms and radio technology will still be appropriate.

Industrial and asset tracking

Industrial IoT often adds fixed IP addressing, private networking, VPN connectivity, PLC and SCADA access and strict firewall rules, so buying on data price alone is a serious mistake, and the connectivity architecture should be designed alongside the industrial network. Asset tracking is one of the clearest global eSIM cases, where a tracker crosses several countries, so international deployments must weigh permanent roaming restrictions, roaming costs, local regulations, latency, profile localisation and the battery cost of network searching.

eSIM versus multi-network SIM versus dual-SIM router

These are often treated as the same thing. They are not. A multi-network SIM and an eSIM solve overlapping but distinct problems, and a good architecture can use both.

A dual-SIM router adds a different kind of resilience: a primary operator SIM plus a multi-network IoT SIM, with the router switching if the primary fails, giving physical separation between two services. For critical infrastructure these approaches are not competitors. A sophisticated design might combine dual modem, dual SIM or eSIM, multiple operator profiles, WAN failover and VPN resilience. Resilience is about removing common points of failure, not collecting the most connectivity acronyms.

The hidden benefits: logistics and negotiation

Network switching gets the attention, but manufacturing logistics may matter just as much. A manufacturer selling the same gateway into several countries traditionally holds different stock by connectivity arrangement. With remotely provisionable connectivity it can move towards a single hardware SKU and decide the profile later, cutting inventory complexity, regional stock, manufacturing variants and deployment errors. At scale those savings are substantial.

There is a commercial benefit too. Deploy 50,000 devices on a ten-year contract under the old model and the provider knows that replacing the SIMs means visiting 50,000 devices, which is a weak negotiating position for the customer. If the profile can genuinely be changed remotely, the economics shift. Even if you never migrate, the ability to do so has value, and this may prove one of the most commercially important consequences of SGP.32.

When not to use eSIM, and when SGP.32 makes most sense

eSIM is not automatically the right answer. If you have ten routers, all in the UK, all easy to reach, on a reliable network, with no international deployment and no need to change provider remotely, a conventional IoT SIM may be perfectly adequate. There is little value in adding provisioning complexity just because eSIM is newer. If your need is simply resilient UK connectivity, a well-designed multi-network roaming SIM might solve it without profile orchestration.

SGP.32 becomes compelling when several of these apply: thousands of devices, international deployment, devices that are physically hard to reach, a product life of five years or more, changing network requirements, regulatory uncertainty, expensive engineer visits, multiple connectivity suppliers, manufacturing across markets, a need to localise connectivity, or a desire to reduce provider lock-in. The more boxes you tick, the stronger the case.

It also helps to recognise there are two distinct markets. Improving connectivity for an existing fleet points towards removable eUICC, multi-network connectivity and better SIM management without redesigning hardware. Designing a new product opens up MFF2, SGP.32, eUICC architecture, modem compatibility, profile orchestration and iSIM. These are different projects and should not be lumped together just because both involve the words IoT eSIM.

Hardware and radio still decide what is possible

Long IoT lifecycles make network evolution a real consideration. 3G has already gone from many markets, and 2G retirement varies by country and operator. An eSIM cannot add radio technologies the modem does not support: download a 4G profile to a 2G-only modem and it will not become LTE-capable. eSIM provides subscription flexibility; the modem determines radio capability, so hardware lifecycle and connectivity lifecycle have to be planned together. For new projects, choose the radio technology deliberately, whether that is LTE-M, NB-IoT, LTE Cat 1 or Cat 1 bis, 5G or 5G RedCap.

5G does not change the principle of eSIM, but the combination is interesting for high-bandwidth, low-latency, private 5G, network slicing and fixed wireless applications, where a 5G industrial router with remotely manageable connectivity is a flexible WAN platform. For high-data use, always check tariff restrictions and fair usage: an eSIM that can access 5G does not mean the contract provides unlimited high-speed data. Low-power NB-IoT and LTE-M devices are a strong case in the other direction, because sending someone to replace a SIM undermines the economics of a low-maintenance, battery-powered sensor, though power-saving behaviour, PSM, eDRX and network registration all still matter more than raw flexibility.

Is IoT eSIM more secure than a physical SIM?

Sometimes, with qualification. A soldered MFF2 eSIM is harder to remove casually than a plastic card in an accessible tray, which helps prevent SIM theft, and remote provisioning reduces how often technicians handle SIMs. But eSIM also introduces remote provisioning infrastructure that itself has to be secured. A secure SIM inside an insecure router is still an insecure deployment.

Security should be assessed across the whole lifecycle, from manufacture through provisioning, deployment, operation, profile change and decommissioning, and it depends on device firmware, router configuration, firewall rules, VPN architecture, credential management, the provisioning infrastructure, the management platform, access control, patching and monitoring. The resilience of the radio link itself is part of that picture too. The strongest architecture combines secure hardware, secure provisioning, secure networking and good operational controls.

The buyer’s decision path

If you are evaluating connectivity now, this is the short version. Do you simply need internet access from a device? A conventional IoT SIM may be enough. Do you need access to several networks? Look at multi-network IoT SIMs and roaming. Do you need inbound remote access? Investigate public IP, static IP, private APN and VPN options. Do you have hundreds or thousands of devices? Prioritise the management platform, API, pooled data and automation. Are devices hard or expensive to visit? eSIM and remote profile management become far more valuable. Will devices operate internationally? Investigate roaming, localisation and SGP.32. Are you designing new hardware meant to run for five to fifteen years? SGP.32 belongs in the design discussion. Do you want the ability to change provider after deployment? Investigate genuine profile portability, not merely whether the supplier uses the word eSIM.

The biggest mistake businesses make is buying an IoT eSIM as though it were a mobile phone contract. Start with the application. Document the number of devices, deployment countries, expected lifetime, data consumption, required radio technologies, preferred and alternative networks, IP addressing, inbound access, VPN and security requirements, management and API needs, portability requirements, expected growth and support expectations. Then ask providers to propose against that specification. It produces far more useful answers than “how much is a 1GB IoT eSIM?”.

IoT eSIM is a connectivity strategy, not a different SIM

The most important thing to understand about IoT eSIM is that the interesting part is not the SIM. It is what happens when the network subscription stops being permanently tied to the hardware. For a small deployment that might just mean easier management. For an equipment manufacturer it can mean shipping one hardware design globally. For a CCTV company it can mean choosing connectivity by site rather than stocking several SIMs. For an international tracking business it can mean moving between roaming and local profiles. For a utility deploying for fifteen years it can mean avoiding a costly physical SIM migration halfway through an asset’s life. And for an enterprise procuring tens of thousands of devices, it can change the relationship with providers altogether.

Get the architecture right and eSIM provides greater flexibility, resilience and control across the life of a deployment. Get it wrong and you have simply replaced one type of SIM with another while keeping all the original limitations. The difference is in the questions you ask before signing the contract.

Related reading