August 4, 2026 · eSIM Router, eUICC, eUICC SIM

The plastic eUICC and SGP.32: retrofitting a router estate you already own

At a glance

The trick: A removable eUICC card with IPAe gives an ordinary router genuine SGP.32 remote provisioning, no new hardware.
The catch: The router’s modem must support BIP + STK, and often needs putting into automatic mode with a couple of AT commands.
The surprise: Buying the eSIM variant of most routers gives you SGP.22 plus a vendor cloud, not native SGP.32.
The strategy: Because the card carries the standard, one IPAe card range can run SGP.32 across a mixed, multi-vendor estate under one eIM.

The idea is not the interesting bit. It is well marketed and widely available: vendors from Robustel to the connectivity providers all sell some flavour of “drop a plastic eSIM in the slot and keep your fleet.” What almost nobody writes down is the operational reality, the vendor-specific gotchas, and what happens to a real estate over a ten-year life. So here is that, using Teltonika as the running example because it is the estate most UK operators actually have on the wall.

We will cover what a plastic eUICC really is, the one architectural fork that decides everything, how to check a specific router (with the exact commands for a RUT901), how the different hardware vendors approach it, and how to roll SGP.32 out across a mixed fleet without making a decade-long mess.

Definitions

What a “plastic eSIM” actually is

The name is a small lie. The point of an eSIM is usually that it is embedded and unremovable. What we mean here is a removable eUICC: an ordinary-looking SIM in a standard form factor (2FF, 3FF or 4FF) running a full eUICC operating system rather than a single fixed profile. It holds multiple operator profiles, downloads and switches them over the air, and drops into any router that takes a physical SIM. The intelligence is on the card, so the host needs no soldered eSIM chip to behave like one.

The label on the packet decides what you actually get. There are three GSMA remote-provisioning standards, and they are not interchangeable.

The three eUICC standards
Standard	Built for	Managed by	Right for headless IoT routers?
SGP.02	Early M2M, automotive at scale	SM-SR, heavy integration	Legacy. Rigid, lock-in prone.
SGP.22	Consumer phones, tablets, wearables	LPA + SM-DP+ (device-initiated pull)	Workable with a vendor cloud bolted on, but not designed for it.
SGP.32	IoT and M2M, unattended fleets	eIM + IPA (server-orchestrated)	Yes. Purpose-built.

If you want “switch carriers from a central platform, no human at the device,” SGP.32 is the target. More background on what SGP.32 is.

The fork that governs everything

IPAd versus IPAe

SGP.32 needs an IPA, the IoT Profile Assistant. It takes instructions from the eIM and turns them into actions on the card. It can live in one of two places, and the choice changes your whole deployment.

Fig 1 · With IPAd the router vendor must ship the assistant in firmware. With IPAe the card carries it, so any BIP-capable router qualifies. IPAe is the retrofit route.

IPAd vs IPAe
	IPAd (in device)	IPAe (on eUICC)
Where it lives	Router firmware	The card itself
Firmware change	Required, per model	None
Host requirement	Vendor-implemented IPA	BIP + STK on the modem
Best for	New designs a vendor commits to	Retrofitting existing / mixed fleets

On kit you already own, IPAe is the route. The deeper IPAe-versus-IPAd analysis is on sgp32.co.uk. And IPAe asks exactly one thing of the host.

The one requirement

The modem has to co-operate: BIP and STK

IPAe uses BIP (Bearer Independent Protocol), usually with STK (SIM Toolkit), to open its own channel through the modem and reach the eIM without the host doing anything clever. Most modern modems support both. But “supports” and “enabled and responding automatically” are not the same thing, and this is where field rollouts quietly fail: many modules ship with the toolkit set to manual triggering, so the card’s autonomous provisioning waits for a response that never arrives. Teams have burned weeks on exactly this before realising it was the modem, not the card.

The honest version“Just drop it in” really means: drop it in, confirm the modem does BIP and STK, and put it in automatic mode. Which is a thing you can check in about ninety seconds.

Worked example · Teltonika RUT901

How to check a specific router

You will not find “BIP” or “STK” in the RUT901 datasheet, because it is a modem property, not a router feature. So you interrogate the modem in your unit rather than trusting the spec sheet. The RUT901 is a good example precisely because it hides a trap.

Find out what modem you actually have

A 12-month-old RUT901 almost certainly carries a Quectel EC200A (named in Teltonika’s own firmware changelog). But a product change notice moves standard RUT901 order codes to an in-house LTE module from Q1 2026. Two different RUT901s now exist, and they will not behave identically. Check first, in the WebUI status or over SSH:

gsmctl -A “ATI” gsmctl -A “AT+CGMM” # module model

EC200A means you are on documented Quectel ground. The new in-house module means stop and ask Teltonika, because the commands below are not guaranteed to apply.

Query the toolkit features (read-only, changes nothing)

gsmctl -A “AT+QSTK?” gsmctl -A ‘AT+QCFG=”bip/auth”‘

If both return a value rather than ERROR, the module exposes STK and BIP config and you are in business. If either returns ERROR, that firmware build is not exposing it and no card will fix it.

Put it in automatic mode

gsmctl -A “AT+QSTK=0” # automatic STK responses gsmctl -A ‘AT+QCFG=”bip/auth”,1’ # enable BIP (mind the quotes)

The correct bip/auth value varies: Teltonika’s own 1oT walkthrough uses ,1, at least one field write-up needed ,0. Confirm it with whoever supplies your eUICC rather than guessing.

Caveat worth its weightThe EC200A is a cheaper module than the EC25 in the RUT240 that Teltonika actually tested with a plastic eSIM. Same vendor, same command family, but reduced-cost modules sometimes carry thinner toolkit support. Prove it on one unit before you order a box of cards.

Procurement

What to check, and what to ask

Check in the spec

Does the modem support BIP and STK?
Can it run the toolkit in automatic mode, not just manual?
Can you reach the AT interface (SSH / CLI) to enable it?
Is there a free slot of the right form factor?
What is the exact modem module and firmware, not the router’s marketing name?

Ask the providers

Is the card SGP.32-certified, with IPAe specifically?
Which eIM manages it, and is it carrier-independent?
Do you have a tested-device list with my exact router and modem on it?
Does the bootstrap profile have coverage at my sites?
Which modem ships in this order code today, and is that changing?

The reality of a real fleet

The mixed estate: four tiers

Almost nobody starts from a blank sheet. After any period of buying kit, an estate splits into tiers that do not interoperate at the eUICC level, and bringing new equipment in sensibly means knowing which tier each box is in.

Fig 2 · Run IPAe cards across tiers 1–4 and one eIM governs the whole estate. Skip them and you manage up to four planes: RMS here, a vendor cloud there, an eIM somewhere else.

The four estate tiers
Tier	Hardware example	eUICC standard	Management	Native SGP.32?
1 · Legacy	Older RUT901, physical SIM	none	Manual / carrier portal	No
2 · Embedded eSIM	RUT901 eSIM, RUTX50E, RUT200 eSIM	SGP.22	Teltonika RMS	No
3 · Plastic card	Any router + IPAe card	SGP.32	Independent eIM	Yes
4 · Native (future)	Vendor SGP.32 hardware	SGP.32	eIM (vendor TBD)	Yes

The strategic question falls straight out: accept a split estate with RMS on your native-eSIM boxes and an eIM on your carded boxes, or standardise on SGP.32 via IPAe cards across everything so one eIM governs the lot. Decide it deliberately, at the start, not by accident three purchase orders in.

The mess nobody prices in

When your vendor adopts SGP.32

Teltonika will ship native SGP.32 eventually; the certified silicon exists and they have already dipped in via SGP.32 bootstrap connectivity with Tele2. The question is what it does to your estate, and the answer is: it does not clean anything up. It adds a generation.

You cannot upgrade an SGP.22 eUICC to SGP.32. The eUICC OS is fixed at manufacture and the migration is a hardware swap, not an over-the-air push. Every embedded-eSIM box you have already deployed stays SGP.22-plus-RMS for life. Industry guidance already tells estate owners to plan for three to five years of parallel operation while natural refresh does the work. So “the vendor adopts SGP.32” is the arrival of a fourth tier on top of the three you have, with a management story (RMS is not an eIM) still to be defined, running in parallel with the in-house modem swap and the IPAd-versus-IPAe choice.

Where the card stops being a trickA removable IPAe card carries the standard itself, independent of the router’s generation, modem or firmware. It decouples your management standard from your hardware-refresh cycle. Four tiers each dragging their own management plane, or one carrier-independent eIM across the lot. The mess is coming; the card is one of the few things that lets you opt out of most of it.

It is not a free lunch: you pay per card, carry another inventory line, and trade a router-vendor dependency for a card-and-eIM-provider dependency. But a carrier-independent eIM is a far better thing to depend on than a firmware roadmap.

Landscape

How the other manufacturers approach it

Teltonika is the example, not the whole story. Walk any major vendor’s literature and eSIM is front and centre, but the honest question is never “does it have a eUICC chip,” it is “which specification does the management layer implement.” As of 2026 the answer, almost everywhere, is SGP.22 plus a proprietary cloud, with native SGP.32 on the roadmap rather than in the box. The split that matters is embedded (soldered MFF2) versus removable (plastic), and vendor-cloud versus independent eIM.

Industrial router vendors · eSIM approach, 2026 (verify current status before procurement)
Vendor	Current eSIM	Embedded vs plastic	Platform	Native SGP.32
Teltonika	SGP.22	Embedded (select models) + plastic retrofit	RMS	Not yet
Robustel + Kigen	SGP.22	Both: MFF2 for new designs, explicit plastic retrofit for existing	RCMS	Direction stated
Cradlepoint (Ericsson)	SGP.22	Embedded (select models)	NetCloud	Well placed, later
Digi	SGP.22	Embedded (select products)	Digi Remote Manager	Not yet
Sierra / Semtech	SGP.22	Embedded, module heritage	ALEOS / connectivity	Evolving
Milesight	SGP.22	Embedded (select models)	Milesight Development Platform	Not yet
Any router (via card)	SGP.32	Plastic IPAe card	Independent eIM	Yes

Two things stand out. Robustel, with Kigen, is the one vendor loudly marketing the plastic-retrofit story as a first-class option rather than a workaround; we have covered that in detail in the Robustel and Kigen eSIM write-up and the SGP.22 vs SGP.32 technical guide on IoTPortal. And the bottom row is the point of this whole piece: the plastic IPAe card is the one path that behaves the same across every vendor above, which is exactly why it works as an estate-wide strategy rather than a single-box fix. For the full vendor-by-vendor detail, see the industrial connectivity guide on sgp32.co.uk.

Decision

Will a plastic eUICC work for me?

Fig 3 · Four gates. Clear all four and the retrofit is sound; fail one and it is a conversation with your vendor, not a lost cause.

Best practice

Rolling it out without the mess

Architecture & risk

Decide your eIM (carrier-independent) before buying anything.
Treat the bootstrap profile as your biggest single risk; test cold-start at real sites in real coverage.
Pilot one unit per hardware, modem and firmware combination, not per model.
Keep a physical SIM fallback in the second slot where you sensibly can.

Operations & lifecycle

Impose order-code and form-factor discipline; track what modem is in each batch.
Run profile-lifecycle hygiene: name, track, retire.
Design failover around one-active-profile, switch-needs-reinit reality.
Sort out SSH / AT-command access and staging before the boxes scatter.
Document the modem, firmware, commands, eIM and bootstrap for the decade, not the demo.

FAQ

Straight answers

Can I put a plastic eSIM in any router?

Any router with a free physical SIM slot, yes, mechanically. Whether it works depends on the modem supporting BIP and STK so an IPAe card can drive its own provisioning. Most modern modems do, sometimes after an AT-command tweak. Verify the specific modem and firmware.

Does the Teltonika RUT901 support it?

The standard RUT901 has a spare Mini SIM slot and no embedded eUICC, so it is an ideal candidate physically. A 12-month-old unit uses a Quectel EC200A, which is documented Quectel ground; newer units move to an in-house module from Q1 2026, which needs separate confirmation. Check the module, query BIP/STK, and pilot one unit before committing a fleet.

Is a removable eUICC the same as an eSIM?

It is the same technology in a removable form factor. An eSIM is usually a soldered eUICC; a “plastic eSIM” is a eUICC operating system on an ordinary plug-in SIM. Both hold multiple profiles and support remote provisioning.

If I buy the eSIM version of my router, do I get SGP.32?

Usually not. Most industrial eSIM routers, Teltonika included, ship an SGP.22 eUICC managed by a vendor cloud, not native SGP.32. If your architecture needs SGP.32 and an independent eIM, the IPAe plastic card is the route, on old and new hardware alike.

What is BIP, and why does it matter?

BIP (Bearer Independent Protocol) lets the card open its own data channel through the modem to reach the eIM. IPAe depends on it. If the modem cannot do BIP, or is not in automatic mode, the card cannot phone home and provisioning stalls.

Can I upgrade an SGP.22 eUICC to SGP.32 over the air?

No. The eUICC operating system is fixed at manufacture. Moving from SGP.22 (or SGP.02) to SGP.32 is a hardware change, not a firmware push. Plan for years of coexistence rather than a switch-over.

Does a plastic eUICC lock me to one provider?

Only if you let it. Lock-in usually hides in the eIM and the card supplier, not the standard. Insist on a carrier-independent eIM and cards you can point at any operator, and the flexibility you paid for survives.

IPAd or IPAe, which do I need?

For retrofitting existing routers, IPAe: the assistant lives on the card, so no firmware change is needed. IPAd lives in the router firmware and depends on the vendor shipping and maintaining it, which most do not yet.

Reference

Mini glossary

eUICC: The chip capability to hold multiple operator profiles and switch between them remotely.
eSIM: Common name for an eUICC, usually a soldered one. The capability, not a single form factor.
Plastic / removable eUICC: A eUICC in a plug-in SIM form factor (2FF/3FF/4FF). Drops into an existing slot.
SGP.02: The older M2M remote-provisioning standard. Integration-heavy, lock-in prone.
SGP.22: The consumer eSIM standard. Widely deployed; workable for routers with a vendor cloud on top.
SGP.32: The IoT eSIM standard. Server-orchestrated via eIM and IPA, built for unattended fleets.
eIM: eSIM IoT remote Manager. The platform that orchestrates profile changes across a fleet.
IPA: IoT Profile Assistant. Executes eIM instructions on the eUICC. Lives in the device (IPAd) or on the card (IPAe).
BIP: Bearer Independent Protocol. Lets the card open its own channel through the modem to the eIM.
STK: SIM Toolkit. The proactive-command mechanism BIP rides on; must run in automatic mode for IPAe.
SM-DP+: The server that stores and delivers encrypted profiles. SGP.32 reuses the SGP.22 SM-DP+.
Bootstrap profile: A pre-loaded profile giving just enough connectivity to reach the eIM and pull the first real profile.
MFF2: The soldered, embedded SIM form factor. The opposite of a removable / plastic eUICC.
RSP: Remote SIM Provisioning. The umbrella term for downloading and managing profiles over the air.

Keep reading

What is SGP.32 SGP.32 explained & migration eSIM routers hub Robustel & Kigen Industrial connectivity guide The eIM explainer