Is Your Cellular Modem Really Ready for SGP.32? BIP, STK and the Hidden Hardware Problem in IoT eSIM

Buying an eSIM-capable modem does not make your product SGP.32-ready. As of August 2026 the specification is stable, certified eUICC hardware is shipping, and the orchestration platforms that sit above the standard have moved from slideware into general availability. The layer most likely to trip up a real deployment is the one nobody puts on a datasheet: the modem firmware, and whether it actually exposes and enables the SIM Toolkit and Bearer Independent Protocol functions that SGP.32’s on-SIM profile assistant needs. This is the hidden compatibility problem, and it is where a lock most people never budget for quietly lives.

What BIP and STK actually are

Start with the two acronyms the marketing skips.

BIP means Bearer Independent Protocol. It lets an application running on the SIM or eUICC ask the modem to open an IP communications channel on its behalf. The SIM is effectively saying: “I need to reach a remote server, please give me a data bearer.” The modem handles the cellular packet connection, and the SIM application drives the session through proactive commands. Typical BIP operations are conceptually equivalent to open channel, close channel, send data, receive data and request channel status.

STK is the SIM Toolkit, with modern implementations sitting inside the broader USAT (USIM Application Toolkit) family defined by 3GPP. STK lets the SIM send proactive commands to the modem rather than only responding to it. People associate STK with the dated consumer menus of the 2G era (balance, top-up, news), but underneath that interface is a genuinely useful machine-to-machine mechanism: initiating network communications, obtaining device information, receiving events and opening data channels.

This is why SGP.32 has not “invented” anything at the modem layer. It reuses toolkit capabilities that have existed in cellular modules for years. That is good news and bad news at once, which we will come back to.

Why this depends on where the profile assistant runs

SGP.32 introduces the IoT Profile Assistant, or IPA, the component that receives instructions from the eSIM IoT Manager (eIM) and drives profile download, enable, disable and delete on the eUICC. There are two implementations, and the difference decides how much the modem matters. We cover this split in depth in IPAe vs IPAd; the short version follows.

IPAe (embedded) runs inside the eUICC. The chain looks like eIM, then the cellular network, then the modem, then BIP and STK, then the IPAe on the eUICC. The eUICC cannot sprout its own radio, so it has to ask the modem for connectivity through the toolkit. This is the case where modem support for the right BIP and STK functions becomes decisive, and it is the popular choice precisely because it needs no changes to the device application. The provisioning logic lives on the SIM.

IPAd (device) runs on the device instead, typically inside the router or gateway operating system. Robustel, for example, integrates its own profile assistant into RobustOS. Here the device application does the talking to the eIM and the eUICC, so the requirement shifts away from modem toolkit support and towards the host software and its integration work. An industrial Linux router is an interesting SGP.32 platform for exactly this reason: it may already have the modem control, secure storage, HTTPS and CoAP libraries, and update mechanism it needs, so the missing piece is software rather than radio hardware.

“Our modem supports BIP” is not the same as “SGP.32 works”

This is the part that costs teams weeks, so it is worth being precise about.

On several Quectel modules, the toolkit is controlled with the AT+QSTK family. It is tempting to assume you switch it on with AT+QSTK=1. That command enables manual proactive commands, the kind that drive a menu or a tone. But SGP.32’s profile assistant expects the modem to respond to eUICC commands automatically, without a host trigger. The field integrator Simplex Wireless documented losing several weeks to precisely this misunderstanding. What was actually needed on their Quectel hardware was the opposite move plus a BIP setting:

AT+QSTK=0            // disable manual STK triggering, allow automatic mode
AT+QCFG="bip/auth",0 // disable BIP authentication so the eUICC can open the channel

That configuration lets the embedded assistant open its own BIP channel, complete the profile operation and talk to the eIM without the host intervening. The specifics vary by module and firmware, which is the whole point. The same team is candid that, across the modules they have tested, BIP support is sporadic and not guaranteed. For how eSIM plays out on a specific device, our sister site covers Teltonika’s RUT241 eSIM implementation in detail.

Same modem, different firmware, different answer

Two devices can carry what looks like the same module and behave differently, because one OEM ordered firmware with the toolkit enabled and another did not. Cellular modules are commonly shipped with STK enabled, host-managed STK, BIP disabled, a custom terminal profile, or a proprietary eSIM integration, all depending on what the buyer specified. This is normal in the supply chain, and it means the question “does the Quectel EG25 support BIP?” is the wrong one.

The accurate question is longer and much less catchy: does this hardware revision, running this firmware branch, integrated by this router vendor, expose the BIP and STK functions our SGP.32 implementation requires? Chipset matters here too. Module makers build on basebands from Qualcomm, Sequans, Sony Altair, ASR, Unisoc and others, and the underlying platform influences what the module vendor can expose. IPA-capable firmware has become more common in modules released from 2024 onward, but “more common” is not “assume it is there”.

Where the module vendors actually stand (August 2026)

A vendor-neutral read of the public position, current to this month. Treat every row as a prompt to request the IPA support matrix and minimum firmware version for your exact part, not as a guarantee.

The router layer: an eSIM router is not automatically an SGP.32 router

This distinction matters more at the router level than anywhere else, because “eSIM router” is now a common marketing line. Two of the most visible industrial vendors illustrate the two honest positions.

Teltonika ships eSIM routers such as the RUT200 and RUT241 built on the SGP.22 architecture, storing up to seven profiles, managed centrally through its Remote Management System (RMS) with a Tele2 bootstrap relationship across the range. Teltonika frames this as pairing SGP.22’s broad compatibility with SGP.32-style remote management. For an always-on, well-connected router this delivers comparable operational outcomes to native SGP.32 for many fleets. But it is not SGP.32: it does not use the eIM, CoAP transport or the asynchronous management model in the specification, and RMS is a closed system that manages Teltonika devices rather than a hardware-agnostic eIM. We cover this in detail in the Teltonika and Tele2 bootstrap analysis.

Robustel shows the migration path. Its current eSIM routers run SGP.22 with Robustel’s own local profile assistant built into RobustOS. Following a partnership with Kigen announced in October 2025, Robustel’s stated SGP.32 direction pairs an SGP.32-compliant Kigen eUICC with its own IPAd inside RobustOS, working with an external eIM. That gives readers a concrete picture of what a real transition looks like: SGP.22 today, an IPAd firmware path to SGP.32, then eIM-based fleet orchestration. Digi International is another vendor publicly scaling on Kigen’s SGP.32 stack.

Can you upgrade an existing router to SGP.32?

Possibly, and that is the genuinely interesting practical question. If an existing industrial router already has a supported modem with BIP-capable firmware, a suitable eUICC, a capable host operating system, modem control access, enough storage and a firmware update mechanism, there may be no fundamental reason the whole unit has to be replaced. In an IPAd model the vendor could, in principle, add the profile assistant through firmware, which would make SGP.32 much less of a hardware transition than people assume.

The caveats are large. Certification, security, the specific eUICC implementation and vendor support all sit in the way, and “the modem supports BIP” never means “install a script and you have SGP.32”. This is a vendor engineering decision, not a field mod. But it does mean the honest answer to “do we need new hardware?” is often “it depends”, not an automatic yes.

How to actually check a modem

You can get a long way with the modem’s own AT interface before you involve anyone. Connect to it and record the basics:

ATI          // identity string
AT+CGMI      // manufacturer
AT+CGMM      // model
AT+CGMR      // firmware revision

Write down manufacturer, model and firmware revision, then take those exact values to the vendor documentation and ask for the toolkit and BIP support position for that build. What you should not do is copy a generic “type these commands” recipe across every modem, because the commands and the firmware behaviour differ per platform, and changing them blind can break a working device. The evidence you want is the vendor’s IPA support matrix and minimum firmware version for your part number. If a supplier cannot produce that, treat it as an open risk, not a detail.

Where this sits in the lock-in picture

Regular readers will know the argument running through this site: SGP.32 does not abolish lock-in, it relocates it. Our conservation of lock-in piece maps the stickier places it moves to, the eIM control plane, the eUICC operating system fixed at manufacture, the bootstrap profile, and the certified-but-not-truly-interoperable component set.

The modem firmware layer belongs on that map. BIP and STK capability is decided when the OEM orders the firmware build, it is invisible on the datasheet, and it is effectively fixed for the life of the device unless the vendor chooses to change it. That is a lock in the same sense as the others: a capability set at manufacture, controlled by someone other than the buyer, that quietly determines whether the interoperability SGP.32 promises is actually reachable on your hardware. It is the least glamorous lock in the stack and one of the easiest to overlook until a fleet will not provision.

The questions to put to your supplier

Before you commit a design or an order, send these to the module or router vendor. Related reading: our IoT eSIM hardware guide, the bootstrap profile pitfalls, and the full hardware provider checklist.

• Which exact module and hardware revision is fitted, and which firmware revision?
• Does that firmware support USAT / STK and BIP, and are they enabled in this build?
• Can you provide the IPA support matrix and minimum firmware version for this part?
• Is the eUICC SGP.32-compatible, and is the assistant IPAe or IPAd?
• Which eIM platforms and SM-DP+ providers has this device been validated against?
• What bootstrap connectivity keeps the device reachable if provisioning fails partway?
• Which parts of this are GSMA certified, and against which specification version?

The bottom line

In August 2026, SGP.32 is real and shipping, but not evenly across the stack. The specification, the eUICC hardware from vendors such as Kigen and Thales, and orchestration platforms including Kigen’s eIM are all in production. What has not caught up uniformly is the modem and router layer, where BIP and STK support is firmware-gated, inconsistent, and often confused with a plain “eSIM supported” line on a datasheet. The teams that avoid a nasty surprise are the ones treating modem firmware as a first-class question rather than an afterthought. For the wider market picture, see the UK SGP.32 landscape; for the standard itself, what SGP.32 is on our sister site.

This is a moving target. Module firmware, vendor certifications and router roadmaps are changing month to month, so we will refresh this page in three to six months. If you have tested a specific module and firmware against a real SGP.32 profile download, we would like to hear the result and reflect it here.