“Does it support eSIM?” is the wrong question. What decides whether SGP.32 will actually work is whether the parts line up: the module, the eUICC, the firmware and the router. Here is what genuinely supports SGP.32 today, and what is eSIM in name only.
SGP.32 is not a box a device ticks, it is a chain that has to line up. The eUICC layer is mature, with certified MFF2 and 2mm MFF4 chips shipping. Modules are capable from around 2024, but gated by firmware. And most routers sold as eSIM today still run SGP.22, the consumer standard, not SGP.32. Verify the exact part, not the family name.
SGP.32 is a chain, not a checkbox
A device does not have SGP.32 the way it has Wi-Fi. SGP.32 support is a property of a whole chain: the eUICC that holds the operator profiles, the IoT Profile Assistant (IPA) that carries out profile operations on the device, the cellular module and its firmware, and the eIM and SM-DP+ on the server side. If any single link is missing or mismatched, the device is eSIM-capable but not SGP.32-capable. That gap is the source of most disappointment in the current market.
The single most useful habit in procurement is to stop asking whether something supports eSIM and start asking where each link sits and which specification it implements. The rest of this piece walks the chain from the chip outward, because that is the order in which the market has matured: the eUICC is ready, the module depends on firmware, and the router is where the marketing most often runs ahead of the reality.
The eUICC layer: mature and shipping
The chip is the part of the chain that is genuinely ready. Kigen, the Hampshire company spun out of Arm, ships GSMA-certified eUICC hardware in the solderable MFF2 and the newer MFF4, a 2mm by 2mm package launched in January 2026 for space-constrained designs. Its eSIMs carry IPAe, the on-eUICC profile assistant, and in early 2026 its eSIM operating system and hardware achieved GSMA eUICC Security Assurance certification for the IoT (SGP.32) and consumer (SGP.22) standards from a single codebase. Thales offers SGP.32 through its Adaptive Connect product, IDEMIA is strong on the security root of trust, and Giesecke+Devrient rounds out the established names. These vendors typically load their eUICC operating system onto secure-element silicon from STMicroelectronics, Infineon or NXP, evaluated to Common Criteria EAL5+.
One caveat matters more than any brand choice. MFF2 is a form factor, not a connectivity standard. An MFF2 chip can be permanently locked to a single carrier, or it can be fully eUICC-capable and reprogrammable. The package tells you nothing about which. Always confirm the chip is eUICC-capable before you design it in. For a closer look at the chip layer and iSIM, our Kigen deep dive goes further.
The module layer: firmware is the gate
Any eUICC-capable cellular module can, in principle, do SGP.32. In practice it needs IPA-capable firmware, and often a specific minimum firmware version. IPA-capable firmware is common in modules built on chipsets from around 2024 onward, from the likes of Qualcomm, Sequans and Sony Altair, integrated into finished modules by vendors such as Telit, Fibocom, Quectel and u-blox. But capability is model and firmware specific in ways the datasheet headline hides. Some modules ship with no eUICC on board at all, so you add the chip yourself. Others support SGP.32 only on a custom firmware build rather than the shipping release. Both are perfectly good modules; neither is plug and play for SGP.32.
The practical step is unglamorous and essential: ask the module vendor for the IPA support matrix and the minimum firmware version for SGP.32, then validate it on your exact part before you commit a design. It also pays to know where the IPA lives. The IPA can run on the module (IPAd) or on the eUICC itself (IPAe). The placement decides who owns the profile agent and how it gets updated, and an IPAe eUICC can bring SGP.32 behaviour to a module whose own firmware would not otherwise support it.
The router layer: where the label misleads most
This is where buyers get caught. Walk through any router vendor’s 2026 literature and eSIM is everywhere, but most of it is SGP.22, the consumer standard, not SGP.32. Teltonika references eUICC across its RUT range and sells eSIM variants, among them the compact RUT200 eSIM, the RUTM16 and RUTM20, and the rugged 5G RUTC50. Robustel has commercial eSIM deployments in the utility sector with devices such as the R1511e. Cradlepoint, Digi and Sierra Wireless all discuss eSIM capability. None of that is untrue, and none of it is a criticism: when much of this hardware was designed, SGP.32-certified modules were not yet commercially available, so a well-implemented SGP.22 was the sensible choice.
And SGP.22 done well is genuinely useful in a managed fleet. A router management platform, such as Teltonika RMS, Cradlepoint NetCloud, Sierra Wireless ALEOS or Peplink InControl2, can trigger profile changes remotely and add fleet-grade visibility on top of the consumer standard, which covers a great many operational needs today. The trap is not SGP.22 itself; it is assuming a family name implies SGP.32, or even eSIM at all. A standard RUT956, for instance, is best treated as a dual physical-SIM device unless the exact variant and firmware add eUICC support. Full SGP.32 router support is emerging in newer hardware generations, but you confirm it by the exact product code, the datasheet and the firmware, never the range name. Our outdoor 5G router guide and the Robustel SGP.22 interoperability test both show this reality in the field.
The useful question is not whether a router has an eUICC chip. It is which specification the management layer implements. A router can carry a certified eUICC and still be an SGP.22 device, because SGP.32 is defined by the provisioning architecture around the chip, not the chip alone.
iSIM: the step after eSIM
Beyond the discrete eUICC chip sits iSIM, where the SIM function moves into a tamper-resistant area of the modem’s system-on-chip. There is no separate chip, which means less board space, less power, and one fewer component to place, benefits that matter most for small, battery-powered devices. Qualcomm has shipped iSIM-capable silicon since the Snapdragon 8 Gen 2 in 2023, and for IoT its E41 4G Modem-RF pairs with IDEMIA’s iSIM in an EAL5+ pre-certified enclave. Kigen helped pioneer iSIM and, with Vodafone, has taken it to commercial availability.
For a buyer in 2026 the honest read is straightforward. eSIM is the practical purchase now; iSIM is the design criterion for your next product cycle rather than a reason to delay today. It also ties you more tightly to specific silicon, so it is a decision for the design stage, not the procurement stage.
The layers at a glance
| Layer | Where SGP.32 stands | What to verify before buying |
|---|---|---|
| eUICC (the chip) | Mature; certified MFF2 and 2mm MFF4 shipping | eUICC-capable, not a locked MFF2; certified to v1.2; is IPAe present |
| Cellular module | Capable from around 2024 chipsets; firmware-gated | IPA support matrix; minimum firmware; is an eUICC even on board |
| Router or gateway | Mostly SGP.22 today; SGP.32 emerging | Exact product code and variant; which SGP version the management layer runs |
| Management (eIM) | Where operational value and lock-in both sit | Does the eIM support migration to another provider |
That last row is the one buyers underweight. The eIM is not just plumbing; it is where the switching costs and the long-term value live, which is why it deserves as much scrutiny as the connectivity. We take that argument further in a later piece on buying the service rather than the SIM.
Six questions before you buy
Take these to any vendor, about the exact part number rather than the product family, and the answers will tell you quickly whether you are looking at real SGP.32 or eSIM in name only.
- Where does the eUICC live: an MFF2 or MFF4 chip inside the module, or a separate chip on the board?
- Is that eUICC genuinely eUICC-capable, or an MFF2 locked to one carrier?
- Which specification does the management layer implement, SGP.22 or SGP.32?
- What is the module’s minimum firmware version for SGP.32, and where does the IPA sit, IPAd or IPAe?
- Which eIM will manage the fleet, and does it support migration to another provider?
- For this exact product code and variant, is eSIM standard, optional, or absent?
Frequently asked questions
Is my router SGP.32 just because it says eSIM?
Usually not. Most routers on sale that advertise eSIM implement SGP.22, the consumer standard. Check which specification the management layer runs, and confirm the exact product variant and firmware, before assuming SGP.32.
What is the difference between IPAd and IPAe?
It is where the IoT Profile Assistant lives. IPAd runs on the cellular module; IPAe runs on the eUICC itself. An IPAe eUICC can add SGP.32 behaviour without new module firmware, which can simplify a design.
Can I upgrade an SGP.22 router to SGP.32 with a firmware update?
Sometimes, but do not count on it. It depends on the module chipset, its firmware and whether the eUICC and IPA support it. Treat it as something to verify with the vendor for your exact part, not something to assume.
Which eUICC form factor should I design in?
For most industrial designs, a solderable MFF2. Where space is very tight, the 2mm MFF4. iSIM goes further but ties you to specific silicon. Whatever the form factor, confirm it is eUICC-capable and not a locked MFF2.
Does the router brand or the eUICC brand matter more?
Neither on its own. SGP.32 is a chain: module, eUICC, firmware, IPA, eIM and SM-DP+ all have to align. A capable router with a locked SIM, or a certified eUICC in a module without IPA firmware, will not deliver SGP.32.
