You’ve been reading about SGP.32. You understand the problem it solves – SIM profiles managed remotely, no truck rolls, no operator lock-in, proper headless IoT provisioning. So the natural next question is: which router do I buy?
The honest answer, as of mid-2026, is that there isn’t one. Not a native SGP.32 router. Not yet.
That’s not a failure of the standard. It’s a timing issue, and understanding why it exists tells you a lot about how SGP.32 hardware will actually work when it does arrive.
What’s the difference between an eSIM router and an SGP.32 router?
These terms get conflated. They’re not the same thing.
An eSIM router is any router with an embedded SIM – a soldered eUICC chip rather than a removable plastic SIM card. Most eSIM routers currently on the market use the SGP.22 standard, which is the consumer eSIM specification originally designed for smartphones. SGP.22 works reasonably well for routers – you can switch carrier profiles, provision remotely, avoid SIM slots – but it wasn’t designed for the kind of automated, headless, large-scale fleet management that M2M and IoT deployments actually need.
An SGP.32 router would be a router with an eUICC that implements the SGP.32 specification – the IoT-native standard built from scratch for unattended devices. It adds the eIM (eSIM IoT Manager) and IPA (IoT Profile Assistant) components that make true automated, enterprise-scale provisioning possible without any user interaction.
The difference matters in practice. SGP.22 on a router still requires a human-assisted provisioning flow. SGP.32 removes that dependency entirely – the device contacts the eIM, downloads the correct profile, and activates it. No screen. No app. No site visit.
Why don’t SGP.32 routers exist yet?
A router is not a modem. It’s a box that wraps around a modem – the cellular module that actually handles radio access and SIM management. The eUICC chip sits inside that module, not in the router’s main processor.
That’s the dependency chain that explains the delay:
- The SGP.32 specification had to be finalised (done – v1.2 published late 2024)
- Test and certification frameworks had to be completed (done – available from early 2025)
- eUICC vendors had to build and certify compliant SIM chips (in progress – first certified products from 2025)
- Modem module vendors had to integrate certified eUICC chips into their modules and implement the IPA (IoT Profile Assistant) – either IPAd in the module firmware or by supporting IPAe on the eUICC itself
- Router manufacturers then build products around those certified modules
Steps 4 and 5 are where the market is right now. As of early 2025, no module maker had released a module with a native IPAd implementation. That has been changing through 2025 and into 2026, but certified, production-ready SGP.32 modules are still rolling out. Router products built on those modules follow behind by at least one product development cycle.
There’s also a firmware reality: even routers that ship with eUICC hardware sometimes list eSIM functionality as “available with future firmware releases.” The Ericsson Cradlepoint R980 is a current example – it has eSIM capability built in, but the full provisioning integration was pending a NetCloud OS release. That’s an SGP.22 story, but it illustrates the gap between hardware shipping and software being ready.
How will an SGP.32 router actually work?
This is worth explaining clearly, because the architecture is different from how most people imagine it.
An SGP.32 router won’t have a “SGP.32 SIM slot.” There’s no new physical form factor. The SGP.32 eUICC is a chip soldered onto the modem module inside the router – invisible from the outside. What changes is what happens at the software and network management layer.
The key components are:
eUICC – the embedded SIM chip itself, storing one or more operator profiles. This sits inside the modem module.
IPA (IoT Profile Assistant) – the software agent that handles communication between the eIM and the eUICC. On a router, this will most likely run as IPAe – embedded in the eUICC itself – because router firmware is complex and router vendors won’t want to certify a new IPA implementation on their OS. IPAe keeps the complexity on the SIM side and only requires the modem to support BIP/STK functions, which most modern modules already do.
eIM (eSIM IoT Manager) – the server-side platform that sends provisioning commands to the IPA. This is what you, the operator, or your connectivity provider controls. It’s the equivalent of the old SM-SR in the M2M world, but enterprise-portable – you can change eIM providers without touching the hardware.
SM-DP+ – the profile preparation server, unchanged from the consumer eSIM world. Hosts and encrypts the operator profiles before they’re downloaded to the eUICC.
In practice, deploying an SGP.32 router will look like this: the device is manufactured with a bootstrap profile that provides just enough connectivity to call home. It powers up, connects to the network on the bootstrap, contacts the eIM, receives the correct production profile for its deployment location and operator, downloads it, and activates it. From that point, the operator profile can be changed remotely whenever needed – without visiting the site, opening the cabinet, or touching the hardware.
For a fleet manager running hundreds of industrial routers across different sites and potentially different countries, that’s a fundamental change in how connectivity is operated.
What exists today for eSIM routers
Current eSIM router options are SGP.22-based. That’s not nothing – SGP.22 eSIM in a router removes the physical SIM dependency and enables remote carrier switching, which has real operational value. But it’s not the full SGP.32 picture.
The main players in eSIM-capable industrial routing hardware right now:
Ericsson Cradlepoint – the most mature eSIM router ecosystem commercially available. Products like the X20, R980, and the recently announced R2400 include eSIM capability with carrier switching managed via NetCloud. These are enterprise-grade, subscription-managed platforms. They use eSIM (primarily SGP.22 architecture), not SGP.32 native. Cradlepoint’s target market is enterprise IT and public safety – they are not industrial IoT M2M.
Teltonika – the Teltonika RUT200 and RUTX range include eSIM variants with SGP.22 eUICC. Good hardware, RutOS and RMS management are strong, but like others these are SGP.22 implementations for now.
Peplink – eSIM support in selected models, again SGP.22, managed via InControl2.
None of these vendors have announced a shipping product with native SGP.32 architecture as of mid-2026. The GCT Semiconductor / G+D partnership announced in May 2025 to develop SGP.32-capable chips with IPAd support is one of the building blocks that router vendors will eventually draw on – but that’s chip and module level, not a router product.
When will SGP.32 routers arrive?
Realistic expectations:
H2 2026 – early 2027: First SGP.32-capable modem modules reaching production volumes from vendors including Quectel, Telit, Sierra Wireless, and Fibocom. These are the components router manufacturers need.
2027: First router products built around certified SGP.32 modules. High-end enterprise vendors like Cradlepoint are the most likely first movers, given they already have the eSIM management platform infrastructure. Industrial IoT-focused vendors like Teltonika are likely to follow.
2027-2028: Broader availability across the industrial router market. This is when you’d expect to see SGP.32 as a standard option rather than a premium differentiator.
The broad commercial deployment of SGP.32 across the wider IoT ecosystem is expected to accelerate from H2 2026, with significant scale through 2027. Router hardware will track that curve, probably six to twelve months behind pure module or tracker hardware because of the additional integration complexity.
What to do now if you’re specifying routers for IoT deployments
If you’re designing a deployment that will go into service in 2024-2025, you’re working with SGP.22 eSIM routers or conventional physical SIM routers. That’s not a problem – SGP.22 delivers genuine operational value, and physical SIM routers from vendors like Teltonika remain highly capable for most M2M applications.
The practical guidance is:
- Specify eUICC hardware where possible. Even if the router only supports SGP.22 today, you’re laying the groundwork for future profile management flexibility. An eUICC router can, in principle, be transitioned to SGP.32 management if the module firmware supports it later – though this isn’t guaranteed across all hardware.
- Think about the management platform. RMS, NetCloud, InControl2 – the platform matters as much as the hardware. SGP.32 will arrive as a software-layer update on some of these platforms before new hardware SKUs even appear.
- Plan for operator switching. Even with SGP.22, the ability to switch carrier profiles remotely has real value in the UK market given ongoing 2G and 3G network sunsets and commercial flexibility across the main UK IoT operators.
- Watch the module vendors. When Quectel or Telit certifies and ships a production-volume SGP.32 module with IPAd or IPAe support, router products built on those modules are 12-18 months away. That’s the leading indicator to watch.
The SGP.32 SIM question
A common search that lands on this page: SGP.32 SIM. If you’re looking for an SGP.32 SIM card to use in an existing router, here’s the situation.
SGP.32 SIM products – eUICCs running the SGP.32 specification – do exist and are reaching commercial availability. Kigen had the first market-ready eIM compliant with SGP.32 v1.2 in late 2024. G+D, Thales, and others have certified or are certifying products. Connectivity providers including Hologram, Monogoto, and others are building SGP.32 into their platforms.
However, dropping an SGP.32 eUICC into an existing router that was designed for a standard SIM or SGP.22 eSIM won’t automatically give you SGP.32 profile management. The router’s modem needs to support the BIP/STK functions the IPAe implementation relies on, and those need to be correctly configured. Most modern modem modules do support BIP – but support is inconsistent across firmware versions and module brands, and enabling it correctly isn’t always straightforward.
If you’re evaluating SGP.32 eUICC SIMs for existing hardware, check whether the specific modem module in your router supports BIP/STK and verify the configuration before committing to a deployment.
Summary
SGP.32 routers for IoT and M2M don’t exist as finished products in mid-2026. The standard is solid, the eUICC SIM ecosystem is forming, and the modem module layer is where things are being built right now. Router products will follow.
Current eSIM routers using SGP.22 have real value and are worth deploying now. They’re not SGP.32, but they’re not a dead end either – the eUICC hardware you specify today is likely to be the hardware you’re managing via SGP.32 platforms in 2027 and 2028 as firmware and management platform support catches up.
The question “which SGP.32 router should I buy?” will have an answer. It just doesn’t yet.
Looking for SGP.32 SIM connectivity options available now? See our SGP.32 SIM cards overview or read the main SGP.32 explainer for a full breakdown of how the standard works.