SGP.32 is the GSMA specification bringing remote eSIM profile management to IoT devices specifically, distinct from the SGP.22 consumer eSIM standard used in phones, letting a device’s connectivity profile be provisioned and swapped remotely without physical SIM access. A VPS doesn’t replace this connectivity layer, it’s where the device management platform, telemetry collection and dashboards sitting on top of that connectivity actually run, the same architecture covered throughout this site applied to eSIM-connected fleets specifically.
What SGP.32 actually changes, briefly
Before SGP.32, IoT devices using eSIM technology generally relied on adaptations of SGP.22, the consumer smartphone eSIM standard, which assumes a user interface and direct user interaction to manage profiles, a poor fit for a sensor sealed inside an enclosure in a field somewhere. SGP.32 was built specifically for IoT’s constraints: no user interface, often no direct human access at all, and a genuine need to manage eSIM profiles, switching network operator, adding a backup profile, remotely and at scale across potentially thousands of devices. This is a meaningful, IoT-specific advance, not just a rebadged version of the phone standard, and it’s the foundation a growing number of IoT cellular deployments are being built on.
Why this still needs a VPS, not just an eSIM platform
It’s worth being precise about where SGP.32 itself ends and where the rest of an IoT deployment begins. SGP.32 and its supporting infrastructure (typically provided by the SIM or connectivity provider) solve the connectivity and profile-management problem: getting a device online, on the right network, with the ability to remotely switch profiles if needed. They don’t solve what happens to the data once a device is online, dashboards, alerting, historical telemetry, device fleet management beyond just connectivity, which is exactly the layer the rest of this site’s guides cover. A VPS running MQTT, Node-RED and a dashboard, as covered in VPS for IoT: The Complete Guide, sits on top of whatever connectivity layer a device uses, eSIM-based or otherwise, doing the same job regardless.
A practical architecture for an eSIM-connected fleet
Devices provisioned with SGP.32-compliant eSIM connectivity report to the same central VPS as any other connected device elsewhere on this site: MQTT for telemetry, a WireGuard tunnel for secure remote access where direct device reachability is needed, following the pattern in Zero-Touch IoT Fleet Provisioning. The genuinely new piece SGP.32 brings is the ability to remotely manage which network a device is actually connecting through, useful for a device that needs to fail over to a different operator’s profile if its primary network has poor coverage at a specific deployment location, all while the device-management and telemetry layer above it on the VPS remains unaffected by that underlying network change.
Why this matters more for fleets than single devices
The genuine value of SGP.32-based remote profile management compounds with fleet size and geographic spread, similar to several other patterns covered throughout this site. A single device with a fixed, known-good network is fine on a traditional physical SIM. A fleet of hundreds of devices deployed across different regions, each potentially needing a different optimal network operator, or needing the flexibility to switch if a specific operator’s coverage degrades in a specific area, is where remote eSIM profile management genuinely earns its place over a physical SIM that would otherwise need manual swapping, often requiring a site visit, to change.
Where sgp32.co.uk fits
For a deeper, dedicated treatment of SGP.32 itself, the specification, its rollout status, and which connectivity providers currently support it, sgp32.co.uk covers this specific topic in considerably more depth than fits within this site’s broader VPS-for-IoT focus, worth a visit for anyone wanting to understand the standard itself before deciding whether and how to adopt it.
A realistic adoption path
For a team already running a fleet on traditional SIMs and considering a move to SGP.32-based eSIM, the device-management and telemetry side of the deployment, the VPS, MQTT broker, dashboards, doesn’t need to change at all; this is genuinely just a connectivity-layer swap underneath infrastructure that already exists. The migration effort sits almost entirely with the SIM and device provisioning side, working with a provider who supports SGP.32, rather than requiring any rework of the dashboards or data pipeline this site’s other guides cover.
Where LumaDock fits in this picture
Regardless of which connectivity standard sits underneath a fleet, the central VPS hosting the device-management platform itself has the same requirements covered throughout this site: reliable, KVM-based, with comfortable headroom for the device count involved. LumaDock works equally well here as for any other connectivity type covered elsewhere on this site, since from the VPS’s perspective, an eSIM-connected device and a physical-SIM-connected device look identical once their data reaches MQTT.
Frequently asked questions
Does SGP.32 require special hardware in the device itself?
Yes, the device needs an eUICC chip (an embedded, reprogrammable SIM chip) supporting the SGP.32 specification specifically, not just any eSIM-capable hardware; this is a hardware decision made at the device design or procurement stage, not something retrofittable to existing physical-SIM devices.
Is SGP.32 widely supported by UK mobile networks yet?
Support is growing but not universal across every network; checking current support directly with prospective connectivity providers, or via the dedicated coverage on sgp32.co.uk, is worth doing before committing to a device design that assumes it.
Can a VPS-based dashboard show which eSIM profile a device is currently using?
Yes, if the connectivity provider’s platform exposes this via an API, a Node-RED flow can poll it and surface current profile status alongside the rest of a device’s telemetry on the same dashboard, giving one unified view rather than needing to check a separate provider portal.
Does adopting SGP.32 change anything about the security hardening covered elsewhere on this site?
No, the device-management and VPS-side security considerations, covered in the VPS Security Hardening Checklist, remain identical regardless of the underlying connectivity standard; SGP.32 is purely a connectivity-layer change.
Is this relevant for a hobby project, or strictly a business-scale consideration?
Largely a business and fleet-scale consideration; a single hobby device on a standard data SIM has little to gain from SGP.32’s remote profile management, which earns its complexity specifically at the multi-device, multi-region fleet scale this guide focuses on.
How does this relate to the fixed IP SIM guides covered elsewhere on this site?
They’re independent considerations, SGP.32 concerns which network and profile a device connects through, while fixed versus dynamic IP, covered in Do I Still Need a Fixed Public IP SIM If I Have a VPS?, concerns how that connection is made reachable from outside; a device can use either combination depending on its specific requirements.
A worked example: a multi-country fleet
Consider a manufacturer shipping the same IoT device to customers across several European countries, each potentially needing a different optimal network operator for reliable coverage in that specific market. On traditional physical SIMs, this means either pre-loading a different SIM per destination market, real logistics overhead, or accepting a single roaming SIM’s typically worse pricing and coverage compromises. With SGP.32-based eSIM, the same physical device ships identically everywhere, with the correct local network profile provisioned remotely once the device reaches its destination and connects for the first time, collapsing what was previously a genuine supply-chain complexity into a single, identical product line regardless of destination market.
What changes for the device manufacturer, not just the connectivity provider
Adopting SGP.32 is, in practice, primarily a decision made at device design time, the eUICC chip needs specifying into the bill of materials from the start, not retrofitted later. For a business already at the stage of finalising hardware for a new IoT product line and expecting meaningful multi-region deployment or long-term fleet management needs, this is worth raising with hardware engineering early in the design process specifically, since unlike most of the software-layer decisions covered throughout this site, this one genuinely can’t be changed after manufacturing without a hardware revision.
For an integrator working with hardware someone else has already designed and manufactured, the relevant question becomes whether the chosen device already includes SGP.32-compliant eUICC hardware, a specification worth confirming directly with the device manufacturer before assuming remote profile management is available as an option.
The VPS layer sits above all of this, unchanged
It’s worth reiterating the core architectural point: everything this site covers about MQTT brokers, dashboards, WireGuard tunnels and Node-RED automation sits at a layer entirely above the connectivity standard a device uses. An SGP.32-provisioned device, once connected and reporting data, looks identical to a physical-SIM device from the VPS’s perspective: a source of MQTT messages, a peer on a WireGuard tunnel, a row in an InfluxDB measurement. The connectivity layer underneath is genuinely invisible to everything covered in this site’s other guides, which is the right architectural boundary to draw. Change the SIM technology underneath without touching anything above it, or change the VPS infrastructure above without caring what’s underneath: that independence is the correct shape for a well-separated architecture.
Frequently asked questions
Does SGP.32 require special hardware in the device itself?
Yes, the device needs an eUICC chip supporting the SGP.32 specification specifically, not just any eSIM-capable hardware; this is a hardware decision made at the device design or procurement stage, not something retrofittable to existing physical-SIM devices.
Is SGP.32 widely supported by UK mobile networks yet?
Support is growing but not universal; checking current support directly with prospective connectivity providers, or via the dedicated coverage on sgp32.co.uk, is worth doing before committing to a device design that assumes it.
Can a VPS-based dashboard show which eSIM profile a device is currently using?
Yes, if the connectivity provider’s platform exposes this via an API, a Node-RED flow can poll it and surface current profile status alongside the rest of a device’s telemetry on the same dashboard.
Does adopting SGP.32 change anything about the security hardening covered elsewhere on this site?
No, the device-management and VPS-side security considerations remain identical regardless of the underlying connectivity standard; SGP.32 is purely a connectivity-layer change.
How does this relate to the fixed IP SIM guides covered elsewhere on this site?
They’re independent considerations: SGP.32 concerns which network and profile a device connects through, while fixed versus dynamic IP concerns how that connection is made reachable from outside. A device can use either combination depending on its specific requirements.
The integration between eSIM management and the VPS-side stack
A natural question for anyone building an SGP.32-based fleet: can the VPS itself trigger eSIM profile switches, not just receive telemetry from devices? In principle yes, via the connectivity provider’s API, if they expose one. A Node-RED flow watching for a device reporting poor signal quality on its current network could automatically call the provider’s API to initiate a profile switch to a backup operator, creating a genuinely automated failover at the connectivity layer. In practice, this depends entirely on what the specific provider exposes via API; not all do, and this is worth verifying directly before designing an architecture that depends on it. In the meantime, the VPS-side MQTT and dashboard stack remains entirely unaffected by which network a device connects through, because the connectivity standard is genuinely invisible to everything running on the server. The connectivity layer below and the application layer above are genuinely separate, which is the correct separation of concerns for maintainable IoT infrastructure.
What to look for when evaluating an SGP.32-compatible connectivity provider
The considerations worth asking about explicitly when evaluating a provider for an SGP.32-based deployment: which operators and regions are covered by available profiles, what the process for remotely triggering a profile switch actually looks like from the integrator’s side, whether a management API exists and how it’s authenticated, what the pricing model is per profile switch versus per-profile subscription, and whether the provider supports the specific eUICC hardware in the devices being deployed. These are commercial and operational questions as much as technical ones, worth asking before hardware has been procured and device designs locked in. Getting these answers before design lock-in is significantly cheaper than discovering gaps after manufacturing.