The Future of Industrial Cellular Connectivity: SGP.32, eSIM, eIM Platforms, Industrial Routers and the Evolution of IoT Connectivity

A definitive industry reference guide for IoT architects, network engineers, procurement teams, industrial automation specialists, MNOs, MVNOs and enterprise connectivity managers.

Published: SGP32.co.uk | Edition: 2026

Contents

1. Executive Summary
2. Definitions and Terminology
3. History of Cellular Connectivity
4. SGP.02, SGP.22, SGP.31, SGP.32 and SGP.33
5. Why SGP.32 Exists
6. Why Today’s eSIM Routers Are Not Yet SGP.32 Routers
7. Complete SGP.32 Architecture
8. The Future of Industrial Routers
9. Industrial Router Vendor Analysis
10. Modems
11. PLMN Selection, Network Steering and the Roaming Myth
12. Resilience
13. Security
14. MNO vs MVNO: How SGP.32 Changes the Balance of Power
15. LTE-M, NB-IoT, Cat 1 bis and RedCap
16. Private APNs, VPNs and Remote Access
17. Should Customers Wait for SGP.32?
18. Procurement Guide
19. Predictions to 2031
20. Frequently Asked Questions
21. Conclusion
22. Glossary

Section 1 – Executive Summary

Answer-first summary: SGP.32 is the GSMA’s third major eSIM specification, designed specifically for headless and constrained IoT devices. It introduces a new management architecture that separates profile download from device-level user interfaces, enabling remote SIM provisioning at industrial scale without physical access. It matters because it closes the last significant gap in eSIM standardisation – the gap between consumer devices and the billions of industrial, utility and infrastructure devices that have no screen, no user and no predictable location.

What Is SGP.32?

SGP.32 is a GSMA technical specification governing the remote management of embedded SIMs (eSIMs / eUICCs) in IoT and M2M devices. Published in 2023, it defines a new architecture that enables network operators, MVNOs and enterprise customers to remotely switch, download and manage connectivity profiles on devices in the field – without physical access, without a local user interface, and without the limitations that made earlier eSIM standards unsuitable for industrial deployments.

Why Does It Exist?

The two earlier commercial eSIM standards – SGP.02 (M2M) and SGP.22 (consumer) – were not designed for the realities of industrial IoT at scale. SGP.02 required always-on server infrastructure and complex certificate management. SGP.22 required a local user to initiate profile downloads. Neither worked well for devices deployed in remote locations, devices with power constraints, or devices that need to switch operators automatically based on signal conditions or commercial decisions.

SGP.32 resolves this by introducing an eSIM IoT Manager (eIM) platform that can push profile management commands to devices asynchronously, and by defining a lightweight IoT Profile Assistant (IPA) that runs on the device itself without needing a local UI.

Why Does It Matter?

The global IoT device estate is enormous. GSMA Intelligence consistently places cellular IoT connections above 3 billion by the mid-2020s, with utility metering, industrial automation, EV charging, surveillance and transportation representing the largest segments. The majority of these devices are headless – they have no user interface, they run unattended, and they need to operate continuously for years or decades. SGP.32 is the first eSIM standard that genuinely addresses this population at scale.

It matters for:

• Operators and MVNOs who want to retain customers by making network switching a platform advantage rather than a customer exit route.
• Enterprise buyers who want to decouple hardware procurement from operator lock-in.
• Device manufacturers who want to ship a single global SKU with no physical SIM logistics.
• System integrators who need to manage large estates of remote devices without site visits.
• Industrial automation specialists who need deterministic, reliable connectivity across multi-national deployments.

The Critical Point Most Commentary Misses

An SGP.32 deployment is not the purchase of an eSIM. It is the assembly of an interconnected stack:

Router + Modem + eUICC + eIM Platform + Operator + VPN + Management Platform

Every layer matters. A perfect eSIM specification running on a poorly chosen modem, behind a misconfigured router, with no VPN recovery logic, will fail operationally. SGP.32 is the protocol layer. The operational outcome depends on the entire stack.

This is the argument that barely exists anywhere in the industry today. This document makes it.

What Will Change Over the Next Five Years?

• Hardware: eUICC chips and SGP.32-compliant modems will become standard in new industrial router designs.
• Software: eIM platforms will emerge as a new class of enterprise software, comparable to MDM for SIM management.
• Operators: MVNOs with multi-MNO access and strong eIM platform capabilities will gain competitive advantage over traditional MNOs.
• Logistics: Physical SIM swap operations will reduce substantially in new deployments.
• Security: The attack surface for SIM-related fraud and interception will shift from physical to software layers.
• Procurement: Tendering for cellular connectivity will increasingly include eIM platform requirements alongside price and coverage.

What Should Businesses Do Now?

1. Audit existing device estates for eUICC hardware readiness.
2. Engage SIM and connectivity suppliers about their SGP.32 roadmaps.
3. Specify eUICC hardware in all new procurement – even if eIM is not yet live.
4. Pilot eIM platforms with limited deployments before committing to scale.
5. Do not delay non-SGP.32 deployments waiting for full market maturity – the transition will be gradual, not a cliff edge.

Section 2 – Definitions and Terminology

Answer-first summary: Industrial cellular connectivity involves a large and sometimes inconsistently used vocabulary. The definitions below reflect GSMA technical specifications and accepted industry usage.

SIM (Subscriber Identity Module)

A physical or embedded integrated circuit that stores the cryptographic credentials used to authenticate a mobile device to a cellular network. The SIM contains the IMSI (subscriber identity), authentication keys and service parameters. Traditional SIMs are removable plastic cards in various form factors (2FF, 3FF, 4FF).

M2M SIM

A SIM designed for machine-to-machine applications. M2M SIMs are typically industrial-grade – conforming to ETSI and JEDEC environmental specifications for temperature, humidity and vibration. They are commonly produced in MFF2 (soldered) form factors to prevent removal or tampering in field deployments.

IoT SIM

A commercial term for SIM products marketed to Internet of Things applications. IoT SIMs frequently offer multi-network access, private APNs, fixed IP addressing and management portal access. The term is not formally standardised and is used interchangeably with M2M SIM by many suppliers.

eSIM (Embedded SIM)

An eSIM is a SIM that is soldered or embedded permanently in a device and whose credentials can be remotely provisioned and updated without physically replacing the hardware. The term eSIM refers to the commercial concept; the underlying technology is the eUICC. Note: eSIM in consumer devices (smartphones, wearables) operates under SGP.22. eSIM in IoT and M2M devices operates under SGP.02 or SGP.32.

eUICC (Embedded Universal Integrated Circuit Card)

The hardware component at the centre of the eSIM ecosystem. An eUICC is a tamper-resistant secure element that can store multiple connectivity profiles simultaneously and switch between them under software control. The eUICC specification is defined by GSMA and covers the chip architecture, security requirements, profile structure and remote management interfaces.

IMSI (International Mobile Subscriber Identity)

A 15-digit number that uniquely identifies a subscriber on a cellular network. Format: MCC (3 digits) + MNC (2-3 digits) + MSIN (subscriber number). The IMSI is stored in the SIM/eUICC and is the primary credential used for network attachment. Each connectivity profile on an eUICC contains its own IMSI.

ICCID (Integrated Circuit Card Identifier)

A unique identifier for the physical SIM or eUICC chip, typically 19-20 digits. The ICCID remains constant even when profiles are added, removed or switched. It is used for inventory management and is not transmitted over the air during network registration.

APN (Access Point Name)

A configuration parameter that defines the gateway between the mobile network and an external data network. The APN determines which packet data network a device connects to, and can be used to route traffic through private infrastructure, apply traffic policies or enforce security controls.

PLMN (Public Land Mobile Network)

A cellular network identified by a unique MCC (Mobile Country Code) and MNC (Mobile Network Code) combination. A PLMN is a named operator on a specific national frequency allocation. When a device searches for a network, it compiles a list of available PLMNs from surrounding cell signals.

FPLMN (Forbidden PLMN)

A list stored on the SIM of networks the device must not attempt to register on. FPLMNs accumulate when registration attempts are rejected. Mismanaged FPLMN lists are a common cause of connectivity failure in roaming SIM deployments.

MNO (Mobile Network Operator)

An organisation that owns and operates cellular radio infrastructure (towers, spectrum, core network). UK examples include EE (BT Group), Vodafone, O2 (Telefonica UK) and Three (CK Hutchison).

MVNO (Mobile Virtual Network Operator)

An organisation that sells mobile connectivity using network infrastructure leased from one or more MNOs. MVNOs range from consumer-focused brands to sophisticated IoT specialists with multi-MNO agreements, private APNs and proprietary management platforms.

SM-DP+ (Subscription Manager Data Preparation Plus)

The server infrastructure responsible for securely preparing and delivering connectivity profiles to eUICC devices. In SGP.22 (consumer eSIM), the SM-DP+ is operated by the network operator. In SGP.32, the SM-DP+ interacts with the eIM platform to deliver profiles to devices.

LPA (Local Profile Assistant)

The device-side software component in SGP.22 consumer eSIM. The LPA manages user-facing profile download and switching, typically presenting a UI so the user can scan a QR code or enter an activation code. The LPA requires a local user interaction model and is entirely unsuitable for headless IoT devices.

IPA (IoT Profile Assistant)

A software component defined in SGP.32 that runs on or near the eUICC within an IoT device. The IPA mediates between the eIM platform and the eUICC, accepting profile management commands and executing them without any local user interaction.

IPAd (IoT Profile Assistant – Device)

The variant of the IPA that runs on the device application processor or modem processor. Enables asynchronous profile management.

IPAe (IoT Profile Assistant – eUICC)

The variant of the IPA implemented within the eUICC chip itself. Used for the most constrained devices where running software on the application processor is not feasible.

eIM (eSIM IoT Manager)

The server-side platform that orchestrates SGP.32 profile management. The eIM communicates with SM-DP+ infrastructure to prepare profiles and with IPA components on devices to deliver and activate them. There is no direct equivalent in SGP.02 or SGP.22.

RMS (Remote Management System)

Teltonika’s proprietary cloud platform for managing router fleets. Provides remote configuration, firmware updates, signal monitoring and VPN management. It is a router management platform, not an eIM – an important distinction explained in Section 6.

LTE-M (Long-Term Evolution for Machines)

A cellular standard optimised for IoT devices requiring low power consumption, extended coverage and mobility support. Data rates typically 1 Mbps peak in each direction.

NB-IoT (Narrowband IoT)

A cellular IoT standard optimised for stationary, extremely low-power devices with infrequent small data transmissions. Typically below 250 kbps. Used extensively in utility metering and environmental monitoring.

Cat 1 bis

A 3GPP Release 13 category reducing LTE Cat 1 to single-antenna operation. Data rates up to approximately 10 Mbps download / 5 Mbps upload. Increasingly used in industrial IoT where bandwidth needs exceed LPWA but full LTE is unnecessary.

RedCap (Reduced Capability)

A 5G NR standard (3GPP Release 17) designed for mid-tier IoT. Supports approximately 150 Mbps download and offers significant module cost reductions compared to full 5G NR.

Private APN

Routes device traffic through a dedicated, isolated gateway rather than the public internet. Provides traffic segregation, fixed IP addressing and potential direct enterprise network connectivity.

VPN (Virtual Private Network)

An encrypted tunnel between a device and a remote endpoint. In cellular IoT, VPNs (OpenVPN, WireGuard, IPSec) are used to secure traffic, provide fixed IP addressing and enable remote access.

Section 3 – History of Cellular Connectivity

Answer-first summary: Industrial cellular connectivity evolved from simple GSM data modems through increasingly sophisticated SIM formats, arriving at the current eSIM ecosystem after more than two decades of incremental standards development.

Traditional SIM Cards (1991-2005)

The original SIM card appeared in the first GSM handsets in the early 1990s. M2M applications from this era used standard consumer SIMs in industrial housings – technically inelegant, with problems around vibration resistance, temperature range and moisture ingress.

M2M SIM Evolution (2005-2012)

As cellular data connectivity became mainstream in industrial applications, dedicated M2M SIM products emerged:

• MFF2 form factor: a soldered chip package (8mm x 5mm) eliminating the SIM card socket.
• Extended temperature ratings: industrial SIMs rated to -40C to +105C.
• Multi-IMSI SIMs: early attempts to provide roaming coverage by storing multiple IMSIs.
• Longer commercial lifetimes: M2M SIM products specified for 10+ year operational life.

Roaming SIMs and Multi-Network SIMs (2008-2018)

International roaming SIMs operate on a home network PLMN and use standard roaming agreements. Subject to roaming restrictions, latency from home routing and operator steering that may not select the best available network.

Multi-network SIMs use on-device software to present different IMSIs to different networks. Technically effective but commercially contested – some MNO agreements explicitly prohibit IMSI-applet approaches.

Early eSIM Development (2012-2016)

The GSMA began formal work on remote SIM provisioning in 2012. Key milestones:

• SGP.01 (2013): Initial requirements specification for embedded SIM in M2M.
• SGP.02 (2014, revised 2016): The first deployable M2M remote SIM provisioning standard.
• SGP.21/SGP.22 (2016): The consumer eSIM standard for devices with local user interfaces.

GSMA Standards Evolution (2016-2023)

SGP.02 adoption was slow due to complex certificate management. SGP.22 was unsuitable for headless IoT. SGP.31 (architecture) and SGP.32 (technical specification) were published in 2023, defining a fundamentally different approach.

Section 4 – SGP.02, SGP.22, SGP.31, SGP.32 and SGP.33

Answer-first summary: The GSMA has produced multiple eSIM standards for different use cases. Understanding which standard applies to which device category is essential for any procurement or deployment decision.

SGP.02 – M2M Remote SIM Provisioning

SGP.02 defines remote SIM provisioning in M2M environments using a two-server model:

+----------------+          +---------+          +----------+
|   SM-DP        |<-------->|  SM-SR  |<-------->|  eUICC   |
| (Profile Prep) |          | (Router)|          | (Device) |
+----------------+          +---------+          +----------+

Limitations of SGP.02:

• Requires bilateral agreements between the SM-SR operator and each MNO.
• Certificate management is complex and expensive.
• Profile switching requires the device to be online and reachable.
• No standardised approach for intermittent connectivity.
• Market adoption remained lower than anticipated due to deployment complexity.

SGP.22 – Consumer Remote SIM Provisioning

SGP.22 covers smartphones, tablets and wearables. Introduced the SM-DP+ (combining SM-DP and SM-SR), the LPA and activation codes (QR codes).

+----------+         +---------+         +-------+
| SM-DP+   |<------->|   LPA   |<------->| eUICC |
| (Server) |         |(Device) |         |(Chip) |
+----------+         +---------+         +-------+
                         ^
                         | User scans QR code or enters activation code
                     +-------+
                     |  User |
                     +-------+

Limitations of SGP.22 for IoT:

• Requires an LPA with local user interface capability.
• Profile download must be user-initiated.
• Not designed for headless devices.
• Not suitable for large-scale automated profile management.

SGP.31 – eSIM IoT Architecture

The architecture document that preceded SGP.32. Defines the conceptual model, use cases and high-level requirements. A reference document rather than a deployable specification.

SGP.32 – eSIM IoT Technical Specification

Published in 2023. Introduces the eIM and IPA as new entities.

+----------+      +----------+      +----------+      +----------+
| SM-DP+   |<---->|   eIM    |<---->|   IPA    |<---->|  eUICC   |
|(Profile  |      |(Manager) |      |(Device)  |      | (Chip)   |
| Server)  |      +----------+      +----------+      +----------+
+----------+           ^
                       |
                  +---------+
                  |Customer |
                  |Portal / |
                  |  API    |
                  +---------+

Key advantages of SGP.32:

• eIM can manage profiles asynchronously – commands queue until the device is next online.
• No requirement for continuous device connectivity during management operations.
• Simpler server architecture than SGP.02.
• Bootstrap profile enables factory-loaded minimal connectivity.
• IPA can be implemented on the application processor (IPAd) without changes to the eUICC chip.

SGP.33 – eSIM IoT Compliance

Defines compliance and test procedures for SGP.32 implementations. The certification framework ensuring interoperability between eIM platforms, SM-DP+ servers and eUICC chips from different vendors.

Comparison Table: SGP Standards

Section 5 – Why SGP.32 Exists

Answer-first summary: SGP.32 exists because the realities of industrial IoT deployment made both preceding eSIM standards unsuitable. The specific challenges of headless devices, remote locations, intermittent connectivity and multi-year operational lifetimes demanded a new architectural approach.

The Core Problem: Physical Access

The dominant challenge in industrial IoT connectivity is physical access. A consumer smartphone user can walk into a shop if their SIM needs replacing. A smart electricity meter buried in a pavement chamber cannot. A pipeline pressure sensor in a remote location cannot. A traffic management controller in a motorway underpass cannot.

The economic case for cellular IoT depends heavily on low operational cost per device. Any requirement for site visits to manage SIM credentials collapses the economics of deployments at thousands or millions of units.

Specific Use Cases That Drove SGP.32

Utility Networks and Smart Metering: National smart meter rollouts involve tens of millions of devices expected to operate for 10-15 years. Meter operators cannot afford site visits to swap SIMs if a network changes commercial terms or coverage degrades.

EV Charging: EV charge points are installed across dozens of countries. Charge point operators need consistent, manageable connectivity at scale without rolling service vehicles to each charge point.

CCTV and Video Surveillance: Cellular-connected surveillance cameras are deployed at retail sites, construction locations and infrastructure perimeters. Site visits to physically change SIMs when switching supplier are unacceptable at scale.

Remote Telemetry: Environmental monitoring stations, oil and gas telemetry, river gauges and weather stations frequently operate in locations with no practical physical access. SGP.32’s asynchronous management model is particularly well suited here.

Industrial Automation: Factory automation and process control systems use cellular connectivity for flexibility and resilience. These systems often run continuously and cannot be taken offline for SIM maintenance.

International Deployments: A multinational enterprise deploying asset tracking devices across 30 countries faces an unmanageable SIM logistics problem if each device needs a locally appropriate physical SIM. SGP.32 enables a single eUICC hardware to receive the appropriate profile for each market remotely.

Section 6 – Why Today’s eSIM Routers Are Not Yet SGP.32 Routers

Answer-first summary: This is one of the most important and least understood distinctions in the current market. Many industrial routers shipping today are marketed with eSIM capability but are not SGP.32 routers. Understanding the difference is essential for any procurement decision made in 2025 or 2026.

The Current Reality

Walk through any major router vendor’s literature today and you will see eSIM prominently featured. Teltonika references eUICC in its RUTM series. Robustel has commercial eSIM deployments in the utility space. Cradlepoint discusses eSIM capability. Digi has eUICC hardware in selected products.

None of this is inaccurate. But it is incomplete.

The critical question is not: does this router have an eUICC chip?

The critical question is: which eSIM specification does the management layer implement?

The Three Approaches in Current Industrial Hardware

Approach 1: SGP.22 with LPA The router includes a standard consumer eSIM implementation. Profile management requires either a user-initiated QR code scan or a local activation code entry. This works for initial provisioning in a controlled environment but is unsuitable for remote reprovisioning of deployed headless devices. It is the consumer eSIM standard applied to industrial hardware.

Approach 2: Proprietary remote management The router vendor provides their own platform (Teltonika RMS, Robustel RCMS, Milesight Development Platform, Digi Remote Manager) for remote configuration and SIM management. These platforms are valuable and in many cases excellent. But they are not eIM platforms. They do not implement SGP.32. They provide proprietary profile management that may work well within the vendor’s ecosystem but does not interoperate with standardised eIM platforms from MNOs or MVNOs.

Approach 3: SGP.02 with SM-SR Some vendors, particularly in utility and smart metering verticals, have deployed SGP.02-based solutions. These are true remote SIM provisioning systems but carry the complexity, bilateral agreement requirements and operational overhead that limited SGP.02 adoption overall.

Current State by Vendor

Why This Distinction Matters

A buyer who purchases a router today on the basis of “eSIM support” and then deploys it expecting SGP.32 eIM management will be disappointed. The eUICC hardware may be present. The IPAd software almost certainly is not. The eIM connection almost certainly does not exist.

This does not make current eSIM routers bad products. Teltonika RMS is an excellent platform for managing router estates. Robustel’s SGP.02 deployments serve utility customers well. The distinction matters for:

• Long-lived deployments (10+ years) where SGP.32 migration mid-life is a planning consideration.
• Deployments where MNO or MVNO eIM integration is a procurement requirement.
• Organisations building their connectivity strategy around standardised, interoperable eIM platforms.

The Transition Path

The realistic trajectory for current eSIM routers to become SGP.32 routers:

1. Modem firmware update to expose ES10 interface correctly.
2. IPAd software development and integration by the router manufacturer.
3. Certification of the IPAd implementation against SGP.33.
4. eIM platform selection and integration.
5. Commercial agreements with SM-DP+ providers.

Steps 1 and 2 are within the router manufacturer’s control. Steps 3-5 require ecosystem partners. The timeline from current state to fully commercial SGP.32 deployment is realistically 2027-2028 for leading vendors, later for the broader market.

What Buyers Should Do Now

• Specify eUICC hardware in all new router procurement.
• Ask vendors specifically about SGP.32 IPAd roadmap timelines, not just eSIM hardware presence.
• Distinguish between proprietary remote management platforms and standards-based eIM integration.
• Evaluate current proprietary management platforms on their own merits for current deployments, while planning for SGP.32 transition.

Section 7 – Complete SGP.32 Architecture

Answer-first summary: SGP.32 introduces a layered architecture with distinct server-side and device-side components. Understanding each component is essential for evaluating eIM platforms, specifying hardware and designing resilient deployments.

The eUICC

The eUICC is the physical foundation – a tamper-resistant secure element protecting cryptographic keys and profile data. In SGP.32 deployments, the eUICC:

• Stores one or more connectivity profiles (each containing an IMSI, authentication keys and service parameters).
• Maintains a single enabled (active) profile at any time.
• Can have profiles downloaded, enabled, disabled and deleted under remote instruction.
• Maintains a unique EID (eUICC Identifier) that persists across all profile changes.

eUICCs for SGP.32 must meet GSMA Security Accreditation Scheme (SAS) requirements and carry Common Criteria certification. Hardware form factors include MFF2 (soldered chip, 8mm x 5mm) for industrial applications.

Bootstrap Profiles

A bootstrap profile is a minimal connectivity profile loaded at the factory. It provides sufficient connectivity to allow the device to contact the eIM platform and receive its operational profile.

Factory   -->  Device ships with bootstrap profile
                         |
                         v
Field     -->  Device powers on, connects on bootstrap profile
                         |
                         v
eIM       -->  Detects device registration, pushes operational profile
                         |
                         v
Device    -->  Downloads and activates operational profile
                         |
                         v
Field     -->  Device operates on operational profile

Operational Profiles

An operational profile contains the full credentials for normal device operation on a specific MNO. It includes the IMSI, authentication keys (Ki, OPc), service parameters, SMS centre number and APN configuration. Operational profiles are cryptographically signed and bound to the specific eUICC by its EID, preventing copying to other devices.

The IPA (IoT Profile Assistant)

IPAd (Device-side IPA): Runs on the device application processor or modem processor. Maintains a persistent connection or polling schedule to the eIM, receives profile management commands and translates them into eUICC operations via the ES10 interface.

+------------------------------------------+
|                    Device                |
|  +------------------+  +--------------+ |
|  |  Application     |  |   Modem      | |
|  |  Processor       |  |   (LTE/5G)   | |
|  |  (IPAd)          |  +--------------+ |
|  +------------------+        |          |
|           |                  |          |
|  +------------------+        |          |
|  |   eUICC          |<-------+          |
|  |   (Profile Store)|                   |
|  +------------------+                   |
+------------------------------------------+
           |
           v (cellular data connection)
      [eIM Platform]

IPAe (eUICC-side IPA): Runs within the eUICC chip itself. Used for the most constrained devices. Relies on the cellular connection for communication with the eIM.

The eIM (eSIM IoT Manager)

The server-side platform managing the SGP.32 ecosystem. It:

• Maintains a database of registered eUICC devices (identified by EID).
• Manages the lifecycle of connectivity profiles for each device.
• Communicates with SM-DP+ servers to prepare and retrieve profile packages.
• Delivers profile management commands to devices via the IPA.
• Supports bulk operations for large estate management.
• Provides APIs for integration with customer portals, ERP systems and orchestration platforms.

The eIM can be operated by an MNO, an MVNO, a third-party platform provider or an enterprise operating their own eIM for internal estates.

Full SGP.32 Ecosystem Architecture

+------------------+     +------------------+
|   MNO / MVNO     |     | Enterprise Portal|
|   (Profile owner)|     | (Customer UI)    |
+------------------+     +------------------+
         |                        |
         v                        v
+------------------+     +------------------+
|   SM-DP+         |<--->|   eIM            |
|   (Profile Prep) |     | (IoT Manager)    |
+------------------+     +------------------+
                                  |
                    (Cellular / IP connection)
                                  |
              +---------+---------+---------+
              |         |         |         |
         +--------+ +--------+ +--------+ +--------+
         |Device 1| |Device 2| |Device 3| |Device N|
         | IPAd   | | IPAd   | | IPAe   | | IPAd   |
         | eUICC  | | eUICC  | | eUICC  | | eUICC  |
         +--------+ +--------+ +--------+ +--------+

Key Interfaces

Section 8 – The Future of Industrial Routers

Answer-first summary: SGP.32 makes industrial routers more important, not less. The router becomes the orchestration point for connectivity management, resilience, security and remote access. These roles deepen significantly as eSIM management becomes software-defined.

The Misconception

A common early reaction to SGP.32 is that it will commoditise routers. If the SIM can manage itself, the argument goes, the router becomes a simple pipe. This argument is wrong.

The Full Stack Reality

Consider what a real-world SGP.32 industrial deployment actually requires:

+----------------------------------------------------------+
|  COMPLETE SGP.32 INDUSTRIAL CONNECTIVITY STACK           |
|                                                          |
|  Layer 7: Management Platform (RMS, NetCloud, MDP)       |
|  Layer 6: eIM Integration (IPAd, eIM API)                |
|  Layer 5: VPN / Security (WireGuard, OpenVPN, IPSec)     |
|  Layer 4: Network Selection (PLMN, APN, routing)         |
|  Layer 3: Resilience Logic (watchdog, failover, retry)   |
|  Layer 2: Modem (AT commands, ES10, band selection)      |
|  Layer 1: eUICC / Profile (credentials, bootstrap)       |
|                                                          |
+----------------------------------------------------------+

The router handles layers 2 through 7. The eUICC and profile handle layer 1. SGP.32 changes how layer 1 is managed. It does not change the need for any other layer.

Routers as IPAd Hosts

In the most common SGP.32 deployment architecture, the industrial router’s application processor hosts the IPAd software. The router becomes the eIM client – managing profile downloads, executing switches, confirming status and handling failure cases. This requires:

• A secure, persistent connection to the eIM platform.
• Certificate management for the IPA-eIM interface.
• Logic to handle partial failures (profile download started but not completed).
• Retry and backoff logic.
• Reporting and logging.

Routers that implement this well will be significantly more valuable than those that do not.

Modem Abstraction and Management

The eUICC is physically connected to the modem. The modem handles network registration on the enabled profile and forwards ES10 interface commands from the IPAd to the eUICC. Router manufacturers must maintain this integration across modem firmware updates – a non-trivial ongoing engineering commitment.

Antennas

Profile switching is only valuable if the device can actually connect on the new profile’s network. Antenna performance across the frequency bands used by different MNOs is non-trivial. A router that switches from EE to Vodafone must be able to connect on Vodafone’s deployed bands at the specific location. Poor antenna design wastes the profile management investment.

VPN and Tunnelled Connectivity

When a device switches connectivity profiles, any VPN session built over the previous profile will drop. The router must detect the profile change, tear down the old tunnel and re-establish on the new profile’s network path. The quality of VPN client software in industrial routers varies substantially between products and manufacturers.

Security Enforcement

The router sits at the boundary between the device estate and the network. Traffic filtering, intrusion detection, anomaly detection and DNS security remain router functions regardless of how the SIM is managed. SGP.32 deployments may actually increase the importance of router-level security because a compromised eIM connection through a router could affect an entire device estate simultaneously.

Remote Monitoring

Industrial router platforms provide fleet-level visibility of signal quality, data usage, device status and event logs. This telemetry becomes more important in SGP.32 deployments because it provides the observability needed to validate that profile switches are producing the expected connectivity improvements in the field.

Section 9 – Industrial Router Vendor Analysis

Answer-first summary: The industrial router market is diverse. eSIM support varies widely and SGP.32 readiness is not yet widespread in shipping products. The following analysis covers the major vendors, their current eSIM position and their likely SGP.32 direction.

All vendor assessments reflect publicly available information as of 2026. Verify current capabilities directly with vendors before procurement decisions.

Master Vendor Reference Table

Teltonika

Market Position: Teltonika Networks (Lithuania) is the dominant independent industrial router vendor in Europe and one of the largest globally. The product range spans from basic LTE routers (RUT series) through enterprise-grade dual-SIM/dual-modem devices (RUTM series) to 5G capable products. A very large reseller ecosystem and the connectivity hardware of choice for a substantial proportion of European IoT deployments.

Current eSIM Status: eUICC hardware is available in selected RUTM series products in MFF2 soldered form. Current eSIM management operates through RMS (Remote Management System).

RMS vs eIM – an important clarification: RMS is an excellent fleet management platform providing remote configuration, firmware updates, signal monitoring, VPN management and alerting. It is not an eIM. It does not implement SGP.32. Customers using Teltonika RMS for eSIM management today are using a proprietary approach, not the emerging standard. This is not a criticism of RMS – it is a very capable platform. The distinction matters for buyers who need standardised eIM interoperability.

SGP.32 Direction: Teltonika’s active firmware development cadence, large partner ecosystem and RMS platform foundation position it well for SGP.32 when the eIM ecosystem matures. IPAd integration is a logical next step, likely in the 2027-2028 timeframe for commercial availability.

Strengths: Price-performance ratio. Broad product range. Active firmware development. Very large European reseller network. Dual-SIM/dual-WAN options. Strong RUTM series for demanding applications.

Weaknesses: RMS is proprietary with limited open API exposure. SGP.32 roadmap not publicly detailed.

Robustel

Market Position: Robustel (China/UK) produces ruggedised industrial routers with a strong track record in utilities, rail and critical infrastructure.

Current eSIM Status: Robustel has been commercially active in eSIM, including SGP.02 deployments in utility metering. This gives Robustel genuine operational eSIM experience beyond most competitors.

SGP.32 Direction: Robustel’s utility market focus and existing SGP.02 experience make SGP.32 a strategic priority. Likely to be among the earlier router vendors with commercial SGP.32 capability.

Strengths: Utility and critical infrastructure relationships. Genuine SGP.02 deployment experience. Ruggedised hardware.

Weaknesses: Smaller scale than Teltonika. Less broad reseller ecosystem in some markets.

Ericsson Cradlepoint

Market Position: Cradlepoint (acquired by Ericsson 2020) is the dominant vendor in enterprise cellular WAN, particularly in North America. NetCloud is highly regarded for enterprise networking integration.

Current eSIM Status: eUICC hardware in selected products, benefiting from Ericsson’s direct operator relationships. NetCloud provides proprietary management. Not SGP.32 currently.

SGP.32 Direction: The Ericsson acquisition gives Cradlepoint unique visibility into operator SGP.32 roadmaps. NetCloud’s API-first architecture is well suited to eIM integration. Likely to be a significant SGP.32 player.

Strengths: Enterprise brand. NetCloud platform depth. Ericsson backing and operator access. US federal market credibility.

Weaknesses: Premium pricing. Historically North America-centric. Less presence in deep industrial OT markets.

Digi International

Market Position: Digi (USA) has a long industrial networking heritage. Digi Remote Manager is an established fleet management platform. Participated actively in eSIM standardisation work.

Current eSIM Status: eUICC hardware available in selected TX and IX series products. Digi Remote Manager provides proprietary management. Not SGP.32.

SGP.32 Direction: Remote Manager is a natural integration point for eIM functionality. Gradual SGP.32 adoption expected, building on standards participation.

Strengths: Long industrial cellular track record. Strong North American presence. Active standards participation.

Weaknesses: European market presence less strong than Teltonika. Some product lines are ageing.

Milesight

Market Position: Milesight (China) produces a competitive range of industrial routers and gateways. Growing European distribution with strong price competitiveness.

Current eSIM Status: eUICC hardware availability increasing. Management through the Milesight Development Platform (the current correct name – not DeviceHub, which is superseded). Not SGP.32.

SGP.32 Direction: Competitive pricing makes Milesight attractive for high-volume SGP.32 deployments. SGP.32 IPAd integration likely to follow market demand.

Strengths: Competitive pricing. Good build quality for the cost tier. Growing European support. LoRaWAN/cellular hybrid gateway range differentiates.

Weaknesses: Enterprise credibility still building. SGP.32 roadmap not publicly confirmed.

Cisco

Market Position: Cisco’s industrial networking range (IR1100, IR1800, IR8300 series) addresses enterprise and critical infrastructure markets. IoT Control Centre is a major cellular management platform.

Current eSIM Status: eSIM capability embedded in roadmaps with specific eUICC hardware varying by product line.

SGP.32 Direction: Operator platform relationships position Cisco for eIM integration. Enterprise customers using Cisco networking are likely to follow Cisco’s SGP.32 path.

Strengths: Enterprise brand. IoT Control Centre platform. Global scale. Strong security portfolio.

Weaknesses: Premium pricing. Complexity. Industrial IoT products less agile than specialist vendors.

Peplink

Market Position: Peplink (Hong Kong) produces multi-WAN routers with SD-WAN capabilities. Popular for transport (buses, trains) and enterprise multi-WAN applications.

Current eSIM Status: Announced eUICC capabilities in selected MAX series hardware. InControl 2 provides cloud management. Not SGP.32 currently.

SGP.32 Direction: Peplink’s SD-WAN focus and multi-WAN aggregation capabilities make it a natural platform for intelligent profile switching alongside physical network failover. The combination of SpeedFusion bonding and SGP.32 profile management could be a meaningful differentiator.

Strengths: SpeedFusion SD-WAN. Multi-WAN aggregation. Transport and enterprise track record.

Weaknesses: Less presence in deep industrial OT markets.

Moxa

Market Position: Moxa (Taiwan) is a major industrial networking vendor with strong OT/ICS credentials. OnCell series covers industrial cellular gateways.

Current eSIM Status: eUICC hardware in development. ThingsPro platform provides a foundation.

SGP.32 Direction: OT focus and IEC/EN certifications make Moxa relevant for critical infrastructure SGP.32 deployments. Adoption will be cautious and certification-led.

Strengths: OT credentials. Industrial certifications. Asian market strength.

Westermo

Market Position: Westermo (Sweden, part of Belden) specialises in ruggedised networking for rail, utilities and industrial automation conforming to EN 50155 and IEC 61850.

Current eSIM Status: Limited eSIM to date. Regulatory certification cycles are longer than commercial markets.

SGP.32 Direction: Rail and utility are primary SGP.32 use cases, but the regulatory environment means adoption will be more deliberate and later.

Strengths: Rail and utility certifications. Ruggedisation. Long product lifetimes.

Weaknesses: High cost. Slower development cycles.

InHand Networks

Market Position: InHand (China) produces industrial routers with strong SCADA and industrial protocol support (Modbus, DNP3, IEC 60870). Growing European and North American distribution.

Current eSIM Status: Growing eSIM support. InHand Device Manager provides cloud management.

SGP.32 Direction: SCADA and protocol support differentiates InHand in industrial automation where SGP.32’s operational benefits are significant.

INSYS icom

Market Position: INSYS icom (Germany) focuses on industrial security gateways with strong presence in German industrial automation. M!DGE router series is well regarded.

SGP.32 Direction: Security gateway focus means eSIM adoption follows security certification cycles. SGP.32 adoption will be selective and deliberate.

Sierra Wireless / Semtech

Market Position: Sierra Wireless’s industrial router heritage (RV55, RX55 series) was acquired by Semtech in 2023.

Current eSIM Status: Sierra had SGP.02 deployments in utility and oil/gas. Semtech acquisition impact on router product roadmap requires direct verification.

SGP.32 Direction: Customer base in utilities and oil/gas has strong SGP.32 use case fit. Roadmap continuity under Semtech is a buyer consideration.

Queclink, PUSR, Four-Faith, WLINK, Welotec

These vendors represent the mid and lower tier of the industrial router market. SGP.32 implications depend heavily on modem vendor selection and willingness to invest in IPAd software development. Hardware readiness is likely to precede platform integration by 12-24 months for the more active vendors in this group.

Section 10 – Modems

Answer-first summary: The modem chipset inside an industrial router determines fundamental SGP.32 compatibility. A poor modem implementation can make an otherwise excellent SGP.32 stack fail in the field. Modem selection deserves more scrutiny than it typically receives.

Why Modems Are the Hidden Variable

The eUICC is physically connected to the modem, not directly to the application processor. The modem handles:

• Network registration on the enabled eUICC profile.
• Forwarding ES10 interface commands from the IPAd to the eUICC.
• Reporting network state changes that may trigger profile management decisions.
• Band selection, attach procedure and PLMN scanning.

A modem that does not correctly expose the ES10 interface, implements eUICC commands incompletely or has poor PLMN selection logic will prevent SGP.32 from functioning correctly regardless of the quality of the eIM platform or IPAd software above it.

The Modem Determines More Than Most Buyers Realise

Beyond SGP.32 integration, the modem determines:

• Which frequency bands are supported – critical for multi-MNO SGP.32 deployments.
• How PLMN selection is handled when multiple networks are available.
• How quickly the modem recovers from registration failure.
• How the FPLMN list is managed.
• Whether the modem locks up under sustained attach failures.
• The latency and throughput characteristics of the cellular connection.

Quectel

The world’s largest modem module vendor by volume. The EC, EG, RG and RM series modules are found in the majority of price-sensitive industrial routers. Quectel has been actively developing eSIM capabilities with eUICC hardware available as an option across multiple module series. SGP.32 roadmap activity has been signalled in industry forums.

Quectel’s scale means their SGP.32 implementation quality will substantially determine the overall market’s capabilities, given how many router vendors use their modules.

Fibocom

Fibocom (China) is a significant LTE and 5G module vendor, particularly in the laptop and industrial markets. eUICC hardware is available in selected modules. SGP.32 roadmap activity parallels Quectel’s. Fibocom modules appear in routers from multiple vendors.

Qualcomm

Qualcomm provides the baseband chipset for many module vendors including Quectel and Fibocom. Qualcomm’s Snapdragon X-series and 9205 modem chipsets are common in IoT. Qualcomm’s chipset-level eSIM standardisation activity enables module vendors to implement eUICC support more readily. The Qualcomm chipset’s PLMN selection and attach logic behaviour directly affects connectivity quality in roaming and multi-profile deployments.

MediaTek

MediaTek’s NB-IoT and LTE-M chipsets are widely used in LPWA applications. For SGP.32, the relevant question is whether MediaTek’s constrained IoT chipsets will support IPAe implementations within the eUICC for the most resource-limited devices. MediaTek’s growing share in mid-tier 5G modules brings it into the Cat 1 bis and RedCap space.

Telit Cinterion

Telit Cinterion (formerly Gemalto/Cinterion modules) brings a distinctive heritage in industrial-grade modems with integrated security. The Cinterion EXS range includes eUICC hardware and the company has been commercially active in SGP.02 deployments. SGP.32 is a natural evolution given their industrial customer base and eSIM experience.

Strengths: Long industrial heritage. Real-world eUICC deployment experience. Strong security credentials. Relationships with utility and industrial customers who are SGP.32’s primary market.

Modem Selection Checklist

When specifying modems for SGP.32-capable deployments:

• [ ] Does the modem support eUICC hardware as standard or option?
• [ ] Does the modem firmware expose ES10 interface for IPAd integration?
• [ ] What is the band support list – does it cover all MNOs in the deployment geography?
• [ ] What PLMN selection algorithm does the modem use?
• [ ] How does the modem handle FPLMN accumulation?
• [ ] What is the modem recovery behaviour after sustained attach failure?
• [ ] Is modem firmware updatable in the field?
• [ ] Has the modem been tested with the specific eIM platform being used?

Section 11 – PLMN Selection, Network Steering and the Roaming Myth

Answer-first summary: SGP.32 solves the profile management problem. It does not automatically solve the network registration problem. Understanding the roaming myth is essential for realistic deployment planning and is one of the most under-discussed topics in the industry.

The Roaming Myth

The myth is simple and pervasive:

“A multi-network SIM connects to the best available network automatically.”

The reality is more complicated and in practice more frustrating.

How Network Selection Actually Works

When a cellular device searches for a network, it does the following:

1. Scans available frequencies for cell broadcasts.
2. Compiles a list of detectable PLMNs.
3. Consults the PLMN priority list on the SIM.
4. Attempts registration on the highest-priority available network.
5. If registration fails, it may try lower-priority networks.
6. If registration is rejected, it may add the network to the FPLMN list.
7. The modem’s own internal logic influences each of these steps.

At no point does the device automatically select “the best” network in any meaningful quality sense. It selects the highest-priority available network on which registration succeeds. These are different things.

The FPLMN Problem in Detail

When a network rejects a registration attempt with specific cause codes (“network not allowed”, “PLMN not allowed”), the SIM is instructed to add that PLMN to the Forbidden PLMN list. Future attach attempts on a forbidden PLMN are suppressed.

FPLMN accumulation is a common, underdiagnosed cause of connectivity failure in field deployments. A device can reach a state where it has forbidden multiple viable networks and is attempting to attach on a weak or absent signal from a lower-priority network. The device appears to be working – it is powered on and scanning – but never connects.

The failure mode looks like poor coverage. It is actually SIM configuration corruption.

Clearing the FPLMN list typically requires:

• SIM card pull-and-reinsert (impossible in MFF2 soldered deployments).
• Modem factory reset (loses all configuration).
• AT command to clear the list (requires management access to the modem).

None of these is simple in a device deployed in a remote location. SGP.32 alone does not address FPLMN management directly.

Network Steering vs. Best Network

Network steering refers to mechanisms by which an operator prioritises connections to specific networks. Steered roaming provides commercial predictability for the MVNO but may not deliver optimal signal quality at every location.

SGP.32 changes the steering picture substantially. Rather than steering within a single profile’s PLMN priority list, the eIM can switch to a different profile with different home network credentials and a different PLMN priority list. This is a significantly more powerful capability – but it is only effective if the new profile’s network is actually available and registrable at the device’s location.

Modem Lockup: The Silent Failure

Cellular modems can enter non-responsive states under sustained attach failure conditions. Symptoms:

• The modem reports a registered state while no data flows.
• The modem becomes unresponsive to AT commands.
• The router management platform shows “connected” while no traffic passes.

SGP.32 profile management commands delivered via the cellular connection cannot reach a modem in this state. Recovery requires a modem power cycle, which interrupts any in-progress profile download.

This is a router-level problem requiring router-level watchdog solutions. No amount of eIM sophistication compensates for a modem that is locked up.

What SGP.32 Does and Does Not Solve

Recommendations

• Specify FPLMN management capability in SIM supplier contracts.
• Implement router-level modem watchdogs with automatic power cycle recovery.
• Monitor RSRP/RSRQ and connection state via router management platforms.
• Test PLMN selection behaviour at specific deployment locations before committing to scale.
• Understand the steering policy of any MVNO SIM before deployment.
• Do not rely on SGP.32 profile switching as the primary resilience mechanism. It is a management tool, not a watchdog.

Section 12 – Resilience

Answer-first summary: Resilient cellular connectivity requires layered defences at the SIM, modem, router and application layers. SGP.32 adds a new layer – remote profile management – but does not replace the others.

Failover Architectures

Single SIM, Single Modem: The baseline. Simple, low cost. Suitable for non-critical applications where connectivity loss is tolerable.

Dual SIM, Single Modem: Two SIM positions share one modem. Failover typically 30-120 seconds. Suitable for most industrial applications.

Dual SIM, Dual Modem: Two independent modems, each with its own SIM. Both can operate simultaneously. Maximum resilience at higher cost. Suitable for mission-critical applications.

Cellular Plus Fixed WAN: Cellular as primary or failover to fixed broadband. Very common in enterprise and critical infrastructure.

Bootstrap Profile as Resilience Layer

The SGP.32 bootstrap profile adds a new resilience dimension. If the operational profile fails to connect, the device can fall back to the bootstrap profile to maintain management connectivity. From the bootstrap profile, the eIM can deploy a new operational profile without physical access.

Particularly valuable for remote deployments where physical access is expensive, devices approaching the end of a network contract, and situations where the operational MNO suffers a prolonged outage.

VPN Recovery

When a cellular profile switch occurs, VPN sessions must be re-established on the new profile’s network path. WireGuard’s roaming capability (migrating to a new IP address without session teardown) is particularly advantageous in profile switch scenarios. VPN servers should use dynamic DNS or other mechanisms to be reachable regardless of which cellular path the client is using.

Watchdog Design

Industrial routers should implement multi-layer watchdogs:

Layer 1: Hardware watchdog   -- monitors router processor health
Layer 2: Software watchdog   -- monitors OS and application processes
Layer 3: Modem watchdog      -- monitors modem responsiveness (AT ping)
Layer 4: Network watchdog    -- monitors IP connectivity (ICMP to known endpoint)
Layer 5: Application watchdog -- monitors application-layer responses (HTTP, MQTT)

Each layer has an independent recovery action, from software restart to modem power cycle to full device reboot.

Signal Monitoring

Continuous monitoring of RSRP, RSRQ, SINR and RSSI provides early warning of deteriorating signal conditions before connectivity is lost. Router management platforms should expose this data via SNMP, MQTT or REST API for integration with network operations centre dashboards.

Section 13 – Security

Answer-first summary: eSIM and SGP.32 introduce genuine security improvements over physical SIM management but also introduce new attack surfaces. A balanced assessment requires understanding both protections and residual risks.

eUICC Security Architecture

The eUICC is a tamper-resistant secure element. Key security properties:

• Physical tamper resistance to GSMA SAS and Common Criteria EAL4+ standards.
• Profile isolation: each profile is cryptographically isolated. A compromised profile cannot read credentials from another profile on the same eUICC.
• Cryptographic binding: profiles are bound to the specific eUICC by its EID and cannot be copied to another eUICC.
• Mutual authentication: all interactions between the eUICC and SM-DP+ / eIM use mutual TLS certificate authentication.

eIM Security – The New Battleground

The eIM platform is the most significant new security surface in SGP.32. An eIM that manages thousands or millions of devices is a high-value target. A compromised eIM could push fraudulent profile changes to an entire device estate simultaneously.

eIM security requirements:

• TLS 1.2+ for all API communications.
• Certificate-based authentication for all device and server connections.
• Role-based access control (RBAC) for operator and enterprise user accounts.
• Multi-factor authentication (MFA) for all administrative access.
• Separation of duties for profile approval and deployment.
• Comprehensive audit logging for all profile management operations.
• Rate limiting to prevent bulk unauthorised operations.
• Hardware Security Modules (HSMs) for key management.
• Third-party penetration testing.

Who Controls the eIM Controls the Fleet

This is the strategic security question that most commentary ignores.

Under traditional SIM management, the SIM provider controlled connectivity by controlling the SIM card stock. The device owner had limited ability to override this.

Under SGP.32, the eIM operator controls connectivity by controlling which profiles are available and when they are deployed. If an enterprise allows an MVNO to operate their eIM, that MVNO has significant leverage over the device estate. If an enterprise operates their own eIM, they retain full control.

For large enterprise deployments, the question of eIM ownership is not just a technical decision – it is a strategic and commercial one.

Can eSIM Be Hacked?

A balanced assessment:

What is very difficult:

• Extracting authentication keys from a certified eUICC chip through physical attack. Hardware security is very strong.
• Cloning an eSIM profile to another device. Cryptographic binding prevents this.
• Impersonating a legitimate SM-DP+ or eIM to push fraudulent profiles. Certificate requirements prevent this.

What requires more caution:

• Compromise of the eIM platform server. A compromised eIM could push profile changes to all managed devices. This is a software/operations security problem, not an eSIM hardware problem.
• Man-in-the-middle attacks on TLS connections between IPA and eIM if certificate validation is improperly implemented.
• Social engineering attacks targeting MVNO or MNO account management portals.
• Supply chain risks: eUICC chips or IPAd software from unvetted sources.
• Bootstrap profile attacks: if a bootstrap profile uses weak credentials or connects to an inadequately secured eIM endpoint, it creates an initial access vector.

Private APNs

Private APNs substantially reduce the network-layer attack surface. Traffic does not traverse the public internet between the device and the enterprise endpoint. Private APNs do not protect against attacks originating within the private network and do not protect against compromise of the eIM management channel.

VPN Security

• WireGuard: Modern cryptography (ChaCha20, Curve25519), minimal attack surface, excellent roaming behaviour.
• OpenVPN: Widely supported, mature, higher overhead, larger codebase.
• IPSec/IKEv2: Most interoperable standard, essential for integration with existing enterprise security architecture.

Supply Chain Risks

• eUICC chips should be sourced from GSMA SAS-accredited manufacturers.
• IPAd software should be validated before deployment.
• eIM platforms should undergo third-party security testing.

Section 14 – MNO vs MVNO: How SGP.32 Changes the Balance of Power

Answer-first summary: SGP.32 fundamentally shifts commercial dynamics. MVNOs with strong multi-MNO access, platform engineering capability and eIM investment will gain relative to single-MNO operators. Enterprise customers gain negotiating leverage. MNOs that do not provide competitive eIM platforms risk disintermediation.

eIM Becomes the New Competitive Battleground

From 2010 to 2025, competitive advantage in IoT connectivity came from coverage breadth, pricing, portal quality and support quality.

From 2026 onwards, a new axis emerges: eIM platform capability.

The MVNO or MNO that deploys the best eIM platform – with the best developer APIs, the most reliable profile management, the best analytics and the most seamless enterprise integration – will have a structural advantage that is difficult for competitors to replicate quickly. eIM platforms create integration switching costs: once an enterprise has integrated their ERP, ITSM and network management systems with a specific eIM API, migration to a different platform is expensive.

This rewards platform-engineering-led MVNOs and disadvantages resell-focused MVNOs with no platform differentiation.

Major MNOs

Vodafone: One of the most active MNOs globally in IoT connectivity. Publicly active in eSIM and SGP.32 standardisation. Expected to be among the earlier MNO adopters of commercial SGP.32 services.

EE (BT Group): The UK’s largest network by coverage. Established enterprise IoT offering. BT’s enterprise relationships provide access to large IoT deployment tenders.

O2 (Telefonica UK): Established IoT division, part of Telefonica’s global IoT programme. International presence relevant for cross-border deployments.

Three (CK Hutchison): Historically less prominent in enterprise IoT, building capabilities. 5G SA network investment relevant for future industrial applications.

Deutsche Telekom: Through T-Systems, a major enterprise IoT player, particularly in German industrial markets. Active in eSIM standardisation.

Orange: Active in enterprise IoT across France and Europe. Orange Business Services covers multi-national deployments.

Telefonica: At group level, significant IoT platform investment and active GSMA eSIM standardisation participation.

Key IoT MVNOs

Wireless Logic: UK-based, one of Europe’s largest IoT MVNOs. Multi-MNO access, private APNs, management platform. Active in eSIM.

CSL: Enterprise IoT MVNO with multi-network coverage and management platform.

KORE: US-focused enterprise IoT MVNO with multi-MNO global coverage. Active in eSIM and SGP.02 deployments.

Eseye: UK-based MVNO with AnyNet+ multi-network technology. Among the more publicly visible UK MVNOs in SGP.32 discussions. eSIM-first positioning and strong eIM platform development.

1GLOBAL: International IoT connectivity provider with multi-MNO access.

Cellhire: UK-based, traditional data SIM rental with IoT connectivity services.

BICS: Wholesale carrier and MVNO enabler with extensive international roaming footprint.

JT (Jersey Telecom): Small MNO with active IoT MVNO division. Particularly active in eSIM and frequently cited in SGP.32 discussions. Willing to invest in platform innovation ahead of scale.

Arkessa: UK IoT MVNO with multi-network coverage and management platform.

EMnify: German IoT MVNO with a cloud-native platform and strong API capabilities. API-first approach makes it naturally positioned for eIM integration. Popular with developer-driven IoT deployments.

How SGP.32 Changes MVNO Competitive Dynamics

Strategic MNO Position Under SGP.32

SGP.32 reduces the lock-in provided by physical SIM distribution. An enterprise customer using SGP.32 can, in principle, switch MNO profile across a device estate without physical SIM replacement. MNOs will compete on profile switch speed and reliability, network quality, eIM platform quality and value-added analytics.

Section 15 – LTE-M, NB-IoT, Cat 1 bis and RedCap

Answer-first summary: SGP.32 is not limited to high-bandwidth 5G applications. It is arguably most transformative in low-power, low-data-rate applications where physical SIM maintenance is most economically damaging and devices operate for the longest periods unattended.

LTE-M

Current Position: Coverage in over 50 countries. Module prices have fallen significantly. Strong deployment in Europe, North America and parts of Asia.

Market Adoption: Utility metering, asset tracking, wearable health monitors, alarm systems. Battery life of 10+ years achievable with PSM and eDRX.

SGP.32 Relevance: LTE-M devices are among the most expensive to service physically due to large deployment volumes, wide geographic spread and low revenue per device. SGP.32’s remote profile management is transformative – changing network over the air on a battery-powered meter in a pavement chamber is far preferable to a truck roll.

NB-IoT

Current Position: Widely deployed by European, Chinese and some North American operators. Excels in static, indoor applications with infrequent data.

Market Adoption: Smart meters, parking sensors, building sensors, environmental monitoring.

SGP.32 Relevance: NB-IoT’s most constrained devices may use IPAe rather than IPAd. Profile management on NB-IoT devices is particularly important for long-life applications: a sensor installed in 2025 may need to operate until 2040, through changing network landscapes and operator commercial terms. SGP.32 provides the mechanism to adapt without physical access.

Cat 1 bis

Current Position: Emerging as the practical choice for mid-tier IoT requiring more bandwidth than NB-IoT/LTE-M but at lower cost than Cat 4.

Market Adoption: Industrial gateways, POS terminals, digital signage, lower-resolution CCTV, vending machines. Growing rapidly as module prices fall.

SGP.32 Relevance: Cat 1 bis devices represent exactly the middle-market industrial segment where SGP.32 provides balanced value. Enough data bandwidth to support reliable eIM communication, deployed in quantities and locations where physical SIM management is prohibitively expensive.

RedCap

Current Position: 3GPP Release 17 RedCap commercialisation is beginning. First modules from Quectel and Fibocom appeared in 2024. Network support rolling out as operators upgrade RAN software.

Market Adoption: Industrial wireless sensors replacing proprietary LPWA in higher-bandwidth applications. Video surveillance. Wearables.

SGP.32 Relevance: RedCap’s 5G NR foundation means eUICC is a natural baseline feature. New RedCap module designs should include eUICC from the outset, making SGP.32 implementation straightforward on new platforms. This is the first cellular technology generation where SGP.32 can be assumed from day one rather than retrofitted.

Comparison Table: IoT Cellular Technologies

Section 16 – Private APNs, VPNs and Remote Access

Answer-first summary: Remote access architecture for industrial IoT remains a critical design decision independent of SIM management technology. SGP.32 changes which network’s APN is active. The remote access layer must be designed to survive and recover from profile switches.

Public IP SIMs

SIMs with a public IP address allow inbound connections from the internet to the device. Public IPs are increasingly rare (IPv4 exhaustion) and expose devices directly to internet scanning and attack. Appropriate only where direct inbound access is genuinely required and firewall rules provide adequate protection.

Fixed IP SIMs

Fixed (static) IP SIMs provide a consistent IP address across reboots and reconnections. Simplify remote access and allow firewall whitelisting. Assigned at the APN level. Under SGP.32, a device switching profiles may switch APNs and therefore IP addresses – VPN provides address independence across profile changes.

Private APNs

Private APNs offer the strongest security baseline. Traffic does not traverse the public internet. Typically use MPLS interconnect between operator core and enterprise data centre.

Private APN considerations under SGP.32:

• A profile switch may move a device from one operator’s private APN to another.
• Both APNs must be configured in the device router.
• The enterprise must have private APN arrangements with both operators.
• Profile switch must be coordinated with IP address management.

VPN Technology Comparison

WireGuard: Modern cryptography, minimal attack surface, excellent roaming behaviour. Can migrate to a new source IP without session teardown – particularly valuable in SGP.32 profile switch scenarios. Growing support in industrial router firmware from Teltonika, Peplink and others.

OpenVPN: Widely supported in legacy router firmware and enterprise security infrastructure. More complex, higher overhead, larger codebase. Still the most common choice in the installed base.

IPSec/IKEv2: Most interoperable standard. Essential for integration with existing enterprise security architecture. More complex to configure than WireGuard.

Remote Access Architecture for SGP.32 Deployments

[Device]                [Carrier Network]        [Enterprise]
 eUICC (Profile A)  -->  MNO-A APN  -->  Internet
 eUICC (Profile B)  -->  MNO-B APN  -->  Internet    [VPN Server]
                                               |           |
                       WireGuard tunnel -------+-----------+
                       (IP-agnostic, roaming-capable)
                                               |
                                      [Internal Systems]
                                      SCADA / PLC / NMS

The VPN layer provides connectivity independence from which profile or APN is active. When the profile switches, the VPN re-establishes automatically. The application layer sees no change in the addressing of the remote server.

Section 17 – Should Customers Wait for SGP.32?

Answer-first summary: Most customers deploying industrial cellular connectivity today should not wait for SGP.32 market maturity. The practical calculus depends on deployment timeline, device volume, operational cost of SIM management and willingness to accept a migration path.

Decision Matrix

Pros of Deploying Now

• Connectivity infrastructure is available now. Waiting for SGP.32 maturity means delayed deployments and delayed revenue.
• eUICC hardware can be specified in current procurement even if the eIM software layer is not yet ready.
• MVNO relationships and network quality can be assessed and validated now.
• Operational experience with the device estate is valuable regardless of SIM management method.

Cons of Deploying Now

• Hardware without eUICC capability will require physical SIM replacement if operator switching is needed in future.
• Multi-IMSI applet SIMs may not be compatible with future SGP.32 platforms.
• Some commercial arrangements (SIM lock-in, minimum commitment contracts) may conflict with future SGP.32 flexibility.

Recommended Migration Strategy (2025-2028)

1. Specify eUICC hardware in all new procurement even if eIM software is not yet ready.
2. Use current MVNO SIM management for existing operations.
3. Engage MVNO or MNO partners about SGP.32 platform timelines.
4. Pilot SGP.32 eIM management with a subset of devices when an eIM platform becomes available.
5. Migrate estate management to eIM progressively.
6. Phase out non-eUICC hardware in subsequent refresh cycles.

Section 18 – Procurement Guide

Answer-first summary: Purchasing industrial cellular connectivity in the SGP.32 era requires new questions across hardware, SIM/connectivity, platform and commercial dimensions. The following checklists cover all critical areas.

Hardware Procurement Checklist

eUICC / SIM Form Factor

• [ ] Is eUICC hardware available in this product? Is it MFF2 soldered or removable?
• [ ] Is the eUICC certified to GSMA SAS? What Common Criteria level?
• [ ] What eSIM specification does the eUICC support? (SGP.02, SGP.22, SGP.32)
• [ ] Is IPAd software available from the router manufacturer for this product?
• [ ] Is the IPAd software maintained alongside router firmware with a defined SLA?

Modem

• [ ] Which modem module is used?
• [ ] Does the modem firmware expose the ES10 interface for IPAd integration?
• [ ] What cellular categories are supported?
• [ ] What bands are supported? Are they appropriate for the deployment geography?
• [ ] Is the modem firmware updatable in the field?

Antenna

• [ ] What antenna is included or recommended? Is gain and frequency specification provided?
• [ ] Is MIMO supported and if so how many streams?
• [ ] Is the antenna appropriate for the mounting environment?
• [ ] What is the antenna connector type and cable loss?

Hardware Resilience

• [ ] How many SIM positions are provided (physical plus eUICC)?
• [ ] Is dual-modem available or required?
• [ ] What is the hardware watchdog specification?
• [ ] What is the MTBF for the product?
• [ ] What is the operating temperature range?

SIM and Connectivity Procurement Checklist

Coverage

• [ ] Which MNOs does the MVNO have agreements with in each deployment country?
• [ ] Is roaming steered or unsteered? What is the steering policy?
• [ ] What is the fallback when the primary network is unavailable?
• [ ] Has coverage been verified at the specific deployment locations?

eSIM and SGP.32

• [ ] Does the MVNO operate an eIM platform?
• [ ] Which SGP.32 specification version is the eIM compliant with?
• [ ] Does the MVNO provide bootstrap profiles? What network do they use?
• [ ] What is the API for eIM operations? Is there an SDK or developer documentation?
• [ ] What SLA applies to profile switch completion time?
• [ ] What are the costs per profile switch operation?
• [ ] What are the costs for eUICC registrations?

Private APN

• [ ] Is a private APN available? What is the interconnect arrangement?
• [ ] Is fixed IP addressing available? What IP range is used?
• [ ] What traffic filtering capabilities are available at the APN gateway?
• [ ] Is IPv6 supported?

FPLMN Management

• [ ] How does the MVNO manage FPLMN list accumulation?
• [ ] Can the MVNO remotely clear FPLMN lists on devices?
• [ ] What is the process for recovering a device with a corrupted FPLMN list?

Commercial Terms

• [ ] What is the minimum commitment (volume, duration)?
• [ ] Are there penalties for early termination?
• [ ] What data caps or fair-use policies apply?
• [ ] What happens to eUICC registrations on contract exit? Is data portability available?

Platform Procurement Checklist

Management Portal

• [ ] Does the platform provide per-device signal quality monitoring?
• [ ] Is real-time data usage monitoring available?
• [ ] Are alerts configurable for connectivity loss and signal degradation?
• [ ] Is bulk device management supported?
• [ ] Is profile switch status visible per device?

API

• [ ] Is a REST API available for platform integration?
• [ ] What authentication method is used?
• [ ] Is there webhook support for event-driven integration?
• [ ] What rate limits apply to API calls?

Security

• [ ] Is MFA enforced for platform access?
• [ ] Is RBAC available?
• [ ] Is audit logging available for all management operations?
• [ ] Has the platform undergone third-party security testing?
• [ ] Where is the platform hosted and what are the data residency options?

Section 19 – Predictions to 2031

Answer-first summary: The following predictions are informed by current standards timelines, technology maturity curves and market dynamics. They are presented as considered analysis. Where confidence is lower, this is stated.

Router Evolution

2025-2026 (High confidence): eUICC hardware becomes standard in mid-range and above industrial router products. Router manufacturers publish IPAd implementation timelines. First commercial SGP.32 deployments in utility metering and EV charging from vendors with SGP.02 heritage (Robustel, Telit Cinterion, Sierra Wireless heritage customers).

2027-2028 (High confidence): IPAd integration matures in leading products. Routers with eIM connectivity management become the norm for new industrial deployments. Firmware upgrade paths for existing eUICC hardware enable SGP.32 management on devices already in the field. Dual-modem routers with separate eUICCs per modem provide advanced resilience options.

2029-2031 (Medium confidence): SGP.32-capable hardware assumed in all industrial router procurement. Products without eUICC face buyer resistance in competitive tenders. Router manufacturers differentiate on eIM platform integration quality, analytics depth and automation capabilities rather than eUICC presence alone.

eIM Platform Evolution

2025-2026 (High confidence): Early commercial eIM platform offerings from specialist MVNOs. Eseye, JT, EMnify and Telit Cinterion are the most likely early movers. Platforms are early-stage with limited automation.

2027-2028 (High confidence): eIM platforms mature. Enterprise API integration with ERP, ITSM and network management becomes standard. Competitive market of 10-20 eIM platform providers emerges. White-label eIM platforms available for MVNOs without development resources.

2029-2031 (Medium confidence): eIM consolidates. Market leaders emerge with significant installed bases. AI-driven profile optimisation (automatic switching based on signal analytics, cost modelling and reliability data) appears in leading platforms. eIM integration with SD-WAN and SASE platforms becomes standard.

MNO and MVNO Evolution

Likely (high confidence):

• MVNOs with engineering capability outperform resell-focused MVNOs.
• Consolidation: larger, platform-capable MVNOs acquire or displace smaller ones.
• MNOs invest in SGP.32 platform to defend enterprise accounts.
• Some MNOs exit direct enterprise IoT to focus on wholesale SGP.32 profile provision.

Less certain:

• eIM portability between providers (would require industry standardisation of eIM APIs beyond current scope).
• Enterprise self-operated eIM at significant scale (possible but technically demanding).
• Single global eIM platform dominance (regulatory barriers in some jurisdictions likely prevent this).

Technology Evolution

Likely (high confidence):

• Most new industrial routers support eUICC by 2028.
• Physical SIM slots remain common alongside eUICC for a decade.
• Hybrid SGP.22/SGP.32 estates dominate mid-market through 2029.
• RedCap adoption grows substantially from 2026.
• Cat 1 bis volume increases significantly as NB-IoT/LTE-M reach saturation in primary verticals.
• Private APN plus VPN remains critical security architecture regardless of eSIM adoption level.

Less certain:

• iSIM (integrated SIM within main SOC) at scale in industrial devices – possible but requires significant chip redesign and re-certification cycles.
• Fully software-defined connectivity without router hardware – possible at the edge of the decade in specific applications.
• 6G relevance to industrial IoT within this prediction window – unlikely before 2032.

Security Evolution

Likely:

• Regulatory requirements for eIM platform security certification in major markets.
• Insurance market requirements for eIM security assessment as part of cyber insurance underwriting.
• Nation-state interest in eIM platforms as potential vectors for large-scale connectivity interference.

Counter-measures will include HSM-based eIM key management, zero-trust architectures for eIM-to-device communication, anomaly detection for unusual profile management patterns and formal incident response procedures for eIM compromise scenarios.

The 2031 Vision: Software-Defined Connectivity

By 2030-2031, the most advanced industrial deployments will treat cellular connectivity as a software-defined resource: connectivity profiles are created, switched and optimised automatically based on real-time cost, quality and policy parameters without human intervention. This represents the convergence of SGP.32 with SD-WAN, network observability and AI-driven optimisation.

The router in this vision is not a dumb pipe. It is the intelligent edge node of a software-defined connectivity stack – the point where profile management, VPN, security, routing and observability combine under policy-driven automation.

Section 20 – Frequently Asked Questions

Q1: What is SGP.32 in simple terms? SGP.32 is the latest GSMA standard for managing eSIMs in industrial devices. It allows network operators and enterprises to remotely switch the network credentials on a device without physical access or any local user interaction.

Q2: What is the difference between an eSIM and a traditional SIM? A traditional SIM is a removable plastic card with fixed credentials for one operator. An eSIM is a permanently embedded chip whose credentials can be updated remotely. The core security functions are identical; the difference is in form factor and reprovisionability.

Q3: What is an eIM platform? An eIM (eSIM IoT Manager) is a software platform – typically operated by a network operator or MVNO – that manages the lifecycle of connectivity profiles on SGP.32 devices. It is the equivalent of an MDM system but for SIM profiles rather than device operating systems.

Q4: Is SGP.32 the same as SGP.22? No. SGP.22 is the consumer eSIM standard used in smartphones, requiring a local user to initiate profile downloads. SGP.32 is the IoT standard designed for headless industrial devices where no user is present.

Q5: My router manufacturer says it supports eSIM. Does that mean it supports SGP.32? Almost certainly not yet. Most industrial routers with eSIM support today use SGP.22 or proprietary remote management. Ask specifically: does the router implement SGP.32 IPAd? Does it connect to a standards-based eIM platform? The answers are likely to be no in 2025-2026.

Q6: What is the difference between Teltonika RMS and an eIM platform? RMS is a proprietary router management platform providing remote configuration, firmware updates, signal monitoring and VPN management. It is not an eIM. It does not implement SGP.32. Both are valuable but serve different functions. An eIM manages SIM profiles to a GSMA standard. RMS manages router configuration to Teltonika’s proprietary specification.

Q7: Do I need to replace my current SIM to use SGP.32? Yes. SGP.32 requires an eUICC chip. Existing traditional SIMs and multi-IMSI applet SIMs are not compatible. New hardware with an eUICC is required.

Q8: What is a bootstrap profile? A minimal connectivity profile loaded at the factory. It provides enough connectivity for the device to contact the eIM platform and receive its operational profile. After the operational profile is active, the bootstrap profile is typically disabled.

Q9: How long does a profile switch take? In good conditions, seconds to a few minutes. Under poor signal or high packet loss, longer or requiring retry. SGP.32 includes retry mechanisms and the eIM can monitor and report on switch completion.

Q10: What happens if a profile switch fails partway through? SGP.32 includes rollback mechanisms. If a profile download fails, the device retains its previous active profile. The eIM detects the failure and can retry.

Q11: Can SGP.32 switch profiles automatically based on signal quality? SGP.32 defines the management protocol but not the business logic for triggering switches. Automatic switching based on signal quality is a feature of the eIM platform, not the specification itself. Some platforms will implement this; others will require manual or policy-driven switch initiation.

Q12: Is SGP.32 more secure than a traditional SIM? At the credential level, comparable or better. eUICC tamper resistance, cryptographic profile binding and mutual authentication are all strong. The new risk is the eIM platform, which is a high-value target if it manages large device estates.

Q13: What is the EID and why does it matter? The EID (eUICC Identifier) is the unique permanent identifier for an eUICC chip. It persists across all profile changes and is used to identify the device in the eIM platform. Unlike the ICCID (which relates to a specific SIM card), the EID is tied to the hardware.

Q14: Can multiple profiles be active simultaneously on one eUICC? No. Only one profile can be enabled at a time. Multiple profiles can be stored and switching takes seconds to minutes, but simultaneous activation of multiple profiles is not supported.

Q15: What is the difference between an MFF2 SIM and an MFF2 eUICC? Both are soldered chips. An MFF2 SIM has fixed credentials with no remote reprovisioning. An MFF2 eUICC can store and switch between multiple profiles remotely. They look identical physically but have fundamentally different capabilities.

Q16: Does SGP.32 require always-on connectivity? No. SGP.32’s asynchronous management model allows commands to queue at the eIM and execute when the device is next online.

Q17: Can an enterprise operate its own eIM? In principle yes. Technically capable enterprises could build or buy an eIM platform to operate internally. In practice, most will rely on their connectivity provider’s eIM.

Q18: What is a private APN and do I need one with SGP.32? A private APN routes device traffic through a dedicated gateway rather than the public internet. Not required for SGP.32 but recommended for security-sensitive deployments.

Q19: How does SGP.32 interact with FPLMN lists? Profile switches implicitly reset accumulated FPLMN entries because a new profile has its own clean FPLMN list. However, if the new profile’s priority networks are also unavailable at the device location, the problem will recur.

Q20: What MNO agreements are required for SGP.32? The MNO or MVNO providing the profiles must have agreements with each SM-DP+ operator used and must provide certified eUICC chips. Bilateral requirements are simplified compared to SGP.02 but commercial agreements are still required.

Q21: Is NB-IoT compatible with SGP.32? Yes. SGP.32 is technology-agnostic. NB-IoT devices can use SGP.32, typically with IPAe for the most constrained devices.

Q22: What is the cost of adding eUICC capability to a device? eUICC hardware adds a small premium to module cost – historically a few dollars at volume, falling as eUICC standardises. Commercial cost of eIM management depends on the connectivity provider’s pricing model.

Q23: Can SGP.32 be used with private 5G networks? Yes. Private 5G network credentials can be delivered as an SGP.32 profile, enabling devices to be provisioned onto enterprise private networks without physical SIM distribution.

Q24: What is the difference between steered and unsteered roaming? Steered roaming configures the SIM to prefer specific networks. Unsteered allows the device to select any available network. SGP.32 provides a more powerful alternative: switching the profile entirely to access a different home network with a different PLMN priority list.

Q25: How does WireGuard compare to OpenVPN for industrial IoT? WireGuard offers lower latency, lower overhead and better roaming behaviour. OpenVPN is more widely supported in legacy router firmware. For new deployments, WireGuard is generally preferred where it is supported.

Q26: How does SGP.32 differ from multi-IMSI SIMs? Multi-IMSI SIMs use on-device applet software to switch between IMSI values, impersonating different network subscribers. SGP.32 downloads complete, cryptographically bound profiles from the network. SGP.32 is standards-based and interoperable. Multi-IMSI applet approaches often conflict with MNO terms of service.

Q27: What certifications should an eUICC have? GSMA SAS-UP and Common Criteria EAL4+ or higher. For industrial applications, operating temperature certification (IEC 7816 or equivalent) is also important.

Q28: What happens to the eIM if the connectivity provider goes out of business? eUICC profiles remain functional while underlying MNO agreements are active, but management operations become impossible without an eIM. Address eIM platform continuity in contractual terms, including data portability for eUICC registrations.

Q29: What monitoring metrics matter most for SGP.32 deployments? eIM platform uptime and API latency, profile switch success rate, profile switch completion time, bootstrap profile fallback frequency, RSRP/RSRQ at device level, FPLMN accumulation rate, VPN tunnel uptime per device, data usage per profile.

Q30: How do I test SGP.32 functionality before large-scale deployment? Pilot with 50-200 devices. Test profile download under good and poor signal. Test profile switch during active data sessions. Test bootstrap profile fallback. Test FPLMN recovery. Test eIM API integration with management systems. Measure completion times and failure rates.

Q31: What is the difference between a profile download and a profile switch? A profile download copies a new profile onto the eUICC without activating it. A profile switch enables a different profile. These are separate operations that can be coordinated by the eIM for staged rollouts.

Q32: Can the eIM manage profiles on eUICCs from multiple chip vendors? Yes, provided all eUICC chips are certified to SGP.32. Interoperability is covered by the SGP.33 compliance framework.

Q33: How does SGP.32 affect SIM swap fraud? Cryptographic binding of profiles to specific eUICCs means a physical SIM swap cannot be executed at the hardware level. Social engineering of operator account portals remains a risk at the account management layer.

Q34: How does SGP.32 affect the logistics of device rollout? Factory-loaded bootstrap profiles allow devices to be shipped without operator-specific provisioning. Devices can be deployed anywhere and receive their operational profile via eIM after first power-up, significantly reducing pre-shipment SIM management workload.

Q35: Are there regulatory requirements for eSIM in different countries? Some countries have specific eSIM regulations. Enterprise buyers deploying internationally should verify regulatory status in each jurisdiction. The GSMA maintains guidance on global eSIM regulatory status.

Q36: What is the lifetime expectation for an eUICC in an industrial device? Industrial-grade eUICCs are typically rated for 10-15 years with 500,000 write cycles or more, covering the expected profile management operations for most industrial deployments.

Q37: What is GSMA IoT Safe and how does it relate to SGP.32? GSMA IoT Safe uses the SIM/eUICC as a hardware security root of trust for device identity and communication security. It is complementary to SGP.32 rather than competing. A device could use the eUICC for both SGP.32 profile management and IoT Safe device authentication.

Q38: Who governs SGP.32 and how is it maintained? SGP.32 is governed by the GSMA through the GSMA SAS process and technical working groups responsible for eSIM standards. Device and platform compliance is tested against SGP.33.

Q39: What is the practical difference between eIM-initiated and user-initiated profile management? In SGP.22 (consumer), the user initiates profile download by scanning a QR code. In SGP.32, the eIM operator initiates the process centrally and the device executes it automatically when connected. No user action is required or possible.

Q40: How does modem band support affect SGP.32 profile switching? When a profile switch moves a device from one MNO to another, the new MNO may operate on different frequency bands. If the router’s modem does not support those bands, the profile switch will succeed at the eUICC level but the device will not be able to register. Band support must be verified before specifying profile switches between MNOs.

Q41: What is RedCap and why does it matter for SGP.32? RedCap is a 5G NR variant designed for mid-tier IoT. Its 5G NR foundation means eUICC is a natural baseline feature. New RedCap devices should be designed with eUICC from the outset, making SGP.32 implementation simpler than retrofitting to older platform designs.

Q42: Can I use SGP.32 with an existing SGP.02 eUICC? No. SGP.02 and SGP.32 use different management architectures and eUICC interfaces. A device designed for SGP.02 cannot be managed by an SGP.32 eIM. New SGP.32-certified eUICC hardware is required.

Q43: What is network slicing and how does it relate to SGP.32? Network slicing allows a 5G network to be divided into virtual networks with different quality characteristics. SGP.32 profiles could potentially specify slice access in future, enabling devices to receive not just MNO credentials but also network quality guarantees. This is a future capability rather than a current deployment reality.

Q44: What is the competitive advantage of early SGP.32 adoption for MVNOs? Early eIM platform deployment creates integration switching costs. Enterprise customers who integrate their systems with a specific eIM API face migration costs if they change platforms. First-mover MVNOs with strong platforms and developer ecosystems build durable customer relationships that are harder to displace than commodity SIM pricing competition.

Q45: What is the minimum viable eIM integration for a router manufacturer? At minimum: IPAd software that can communicate with an eIM, execute profile download and switch commands via ES10, and report success or failure. Beyond minimum: configurable eIM endpoint URL, certificate management UI, profile status monitoring and integration with the router’s existing management interface.

Q46: Does SGP.32 improve coverage or signal quality? No. SGP.32 enables switching to a better network, but the coverage of each network at any given location is unchanged. SGP.32 provides access to existing coverage rather than creating new coverage.

Q47: What is the strategic risk of allowing your MVNO to operate your eIM? The MVNO operating the eIM has significant control over the device estate’s connectivity. An enterprise that allows an MVNO to operate their eIM without contractual protections around data portability and service continuity is creating a dependency that may be difficult to exit.

Q48: How do I include SGP.32 requirements in a tender or RFP? Key requirements to specify: eUICC hardware with GSMA SAS certification; SGP.32-compliant IPAd software with confirmed SGP.33 testing; eIM platform with REST API and SLA for profile management operations; bootstrap profile provision; FPLMN management commitment; data portability for eUICC registrations on contract exit; multi-MNO profile availability; profile switch cost structure.

Q49: What is the single most important thing to understand about SGP.32? SGP.32 is a protocol layer, not a complete solution. The outcome in the field depends on the entire stack: router, modem, eUICC, IPAd, eIM platform, operator, VPN and management platform. Each layer must be specified, tested and maintained independently.

Q50: Why do industrial routers become more important under SGP.32, not less? Because SGP.32 adds responsibilities to the router rather than removing them. The router hosts the IPAd, provides the cellular connection on which eIM management commands travel, implements the watchdog logic to recover modem lockups that would otherwise block profile switches, manages the VPN tunnel across profile changes, enforces security at the network boundary and provides the observability telemetry needed to validate that profile switches achieve the intended connectivity improvements. SGP.32 turns the router from a connectivity pipe into a connectivity orchestration platform.

Section 21 – Conclusion

The Past

Cellular connectivity for industrial devices spent its first two decades in a state of structural tension. The technology was designed for consumer handsets. The needs of industrial IoT – long lifetimes, remote locations, headless operation, global deployment, low operational cost – were accommodated through workarounds: ruggedised SIM form factors, multi-IMSI applets, roaming agreements and physical SIM management operations that eroded the economics of every deployment at scale.

SGP.02 was the first genuine attempt at a standards-based solution. It worked in deployments where the complexity and bilateral agreement requirements could be absorbed. But the majority of the industrial IoT market continued managing physical SIMs because the alternative was too hard.

The Present

SGP.32 arrived in 2023 as a considered engineering response to those limitations. It is not a revolution – it is the result of a decade of industry learning about what made SGP.02 hard and what made consumer eSIM inapplicable to industrial contexts. The architecture is sound. The security model is robust. The asynchronous management model genuinely addresses the intermittent-connectivity reality of industrial deployments.

The present challenge is market readiness. As of 2026, SGP.32 is standardised but not yet widely deployed. Most routers marketed as eSIM-capable use SGP.22 or proprietary management, not SGP.32. eIM platforms are appearing from specialist MVNOs. The ecosystem is in early formation – comparable to where LTE was in 2011: standardised, beginning to be deployed, not yet ubiquitous.

Hardware procurement decisions made now should specify eUICC capability. Commercial relationships should include questions about eIM roadmaps. Deployments with 10-year-plus device lifetimes should plan for SGP.32 migration paths.

The Future

The trajectory is clear. SGP.32 will become the default SIM management infrastructure for industrial IoT in the same way that eSIM became standard in consumer smartphones. The timeline is 5-7 years from standardisation to widespread deployment, placing mainstream SGP.32 industrial deployment in the 2028-2030 period.

The implications beyond connectivity management are significant. When SIM credentials become software assets – manageable through APIs, switchable in seconds, independent of physical SIM logistics – the entire competitive structure of the cellular connectivity market changes.

The operator that manages the eIM platform gains a strategic position in the device estate. The enterprise that controls its own eIM retains commercial flexibility. The MVNO with the best platform engineering attracts the best customers. The router manufacturer that implements IPAd well becomes a preferred hardware partner.

For industrial routers, the opportunity is to become the intelligent edge of this new architecture – hosting IPAd software, providing rich management telemetry, integrating with eIM APIs and adding the resilience, security and observability layer that turns a connectivity technology into an operational infrastructure.

SGP.32 is not the end of the router’s relevance. It is the beginning of a new chapter in which the router becomes the most important node in the software-defined connectivity stack.

Section 22 – Glossary

3GPP: 3rd Generation Partnership Project. The international standards body responsible for cellular technical specifications.

APN: Access Point Name. Configuration parameter routing cellular data traffic to a specific network gateway.

Bootstrap Profile: A minimal connectivity profile pre-loaded on an eUICC, providing initial connectivity to contact the eIM platform and receive an operational profile.

Cat 1 bis: Single-antenna LTE variant offering up to 10 Mbps download, optimised for mid-tier IoT.

Common Criteria: International standard (ISO/IEC 15408) for security product evaluation. eUICCs typically certified to EAL4+.

eDRX: Extended Discontinuous Reception. Power saving mechanism in LTE-M and NB-IoT.

EID: eUICC Identifier. The permanent unique identifier for an eUICC chip, persisting across all profile changes.

eIM: eSIM IoT Manager. Server-side SGP.32 platform for IoT profile management. Introduced in SGP.32, with no equivalent in SGP.02 or SGP.22.

eSIM: Embedded SIM. A SIM whose credentials can be remotely provisioned without physical replacement.

eUICC: Embedded Universal Integrated Circuit Card. The hardware chip implementing eSIM functionality.

FPLMN: Forbidden PLMN. A network added to a blacklist on the SIM after registration rejection. Accumulation of FPLMN entries is a common cause of field connectivity failure.

GSMA: GSM Association. The industry body representing mobile network operators; governs eSIM standards including SGP.02, SGP.22 and SGP.32.

HSM: Hardware Security Module. Dedicated hardware for secure cryptographic key management, recommended for eIM platforms.

ICCID: Integrated Circuit Card Identifier. The unique number identifying a SIM or eUICC chip.

IMSI: International Mobile Subscriber Identity. The number identifying a subscriber on a cellular network. Each eUICC profile contains its own IMSI.

InControl 2: Peplink’s cloud management platform for router fleet management.

IPA: IoT Profile Assistant. Device-side SGP.32 component managing profile operations on behalf of the eIM.

IPAd: IPA variant running on the device application processor or modem processor.

IPAe: IPA variant running within the eUICC chip itself, for the most constrained devices.

IPSec: Internet Protocol Security. A suite of protocols for authenticating and encrypting IP traffic.

LPA: Local Profile Assistant. The device-side component in SGP.22 consumer eSIM requiring user interaction. Not used in SGP.32.

LTE-M: Long-Term Evolution for Machines. LPWA cellular standard supporting mobility and voice.

MCC: Mobile Country Code. Three-digit code identifying a country in a PLMN.

MDP: Milesight Development Platform. Milesight’s cloud management platform for router and gateway fleets.

MFF2: Machine Form Factor 2. Solderable SIM/eUICC chip package, typically 8mm x 5mm. Cannot be removed without desoldering.

MNC: Mobile Network Code. Two or three digit code identifying an operator within a country.

MNO: Mobile Network Operator. Owns and operates cellular radio infrastructure.

MTBF: Mean Time Between Failures. Hardware reliability metric.

MVNO: Mobile Virtual Network Operator. Sells connectivity using MNO infrastructure under wholesale agreements.

NB-IoT: Narrowband IoT. LPWA cellular standard for low-power, low-bandwidth applications.

NetCloud: Cradlepoint/Ericsson’s cloud management platform for enterprise cellular WAN.

NTN: Non-Terrestrial Network. Cellular connectivity via satellite or HAPS.

OpenVPN: Open-source VPN protocol and implementation.

PLMN: Public Land Mobile Network. A national cellular network identified by MCC+MNC.

PSM: Power Saving Mode. Device sleep mechanism in LTE-M and NB-IoT enabling extended battery life.

RBAC: Role-Based Access Control. Security model limiting system access based on assigned roles.

RCMS: Robustel Cloud Management System. Robustel’s proprietary router management platform.

RedCap: Reduced Capability. 5G NR variant optimised for mid-tier IoT (3GPP Release 17).

RMS: Remote Management System. Teltonika’s proprietary cloud platform for router fleet management. Not an eIM.

RSRP: Reference Signal Received Power. LTE signal strength measurement.

RSRQ: Reference Signal Received Quality. LTE signal quality measurement.

RSSI: Received Signal Strength Indicator. Overall signal power measurement.

SAS: Security Accreditation Scheme. GSMA programme for certifying eUICC and SM-DP+ security.

SGP.02: GSMA M2M remote SIM provisioning specification, using SM-DP and SM-SR server model.

SGP.22: GSMA consumer eSIM technical specification, using SM-DP+ and LPA model.

SGP.31: GSMA IoT eSIM architecture specification (reference document for SGP.32).

SGP.32: GSMA IoT eSIM technical specification for headless and constrained devices, introducing eIM and IPA.

SGP.33: GSMA IoT eSIM compliance and testing specification.

SINR: Signal to Interference plus Noise Ratio. Signal quality measurement.

SM-DP+: Subscription Manager Data Preparation Plus. Server preparing and delivering eSIM profiles. Shared between SGP.22 and SGP.32 ecosystems.

SM-SR: Subscription Manager Secure Routing. SGP.02 profile routing server. Replaced by eIM in SGP.32.

VPN: Virtual Private Network. Encrypted tunnel providing secure remote access.

WireGuard: Modern VPN protocol with minimal codebase (approximately 4,000 lines), strong cryptography and excellent IP-roaming behaviour. Recommended for new industrial IoT deployments.

This document is published by SGP32.co.uk as an independent industry reference. All vendor assessments reflect publicly available information and are provided for general guidance. Readers should verify specific product capabilities directly with vendors before making procurement decisions. Standards references are based on GSMA published specifications as of 2026.

Focus keyword: SGP.32

Copyright SGP32.co.uk | sgp32.co.uk