Most of the conversation on this site is about SGP.32 – the standard, the architecture, the eIM, the IPA, the gap it closes. But the reality of what is actually shipping and deploying in IoT infrastructure right now is mostly SGP.22. And for the majority of applications, SGP.22 – implemented properly – is not the inferior option it is sometimes made out to be.

Teltonika’s launch of eSIM variants of the RUT200 compact industrial router makes a useful case study. Not because the RUT200 eSIM is a native SGP.32 device – it is not. But because it demonstrates what happens when a hardware manufacturer builds SGP.22 properly and layers serious remote management capability on top of it.

The result is a product that delivers most of what deployers actually need from eSIM – at the lowest price point in Teltonika’s router range.


The Product

The RUT200 is a compact 4G LTE Cat 4 router in a 125 g aluminium IP30 enclosure. It has been widely deployed across CCTV, utilities, remote monitoring and kiosk applications in the UK and Europe. The eSIM variants add an integrated eUICC chip alongside the existing Mini SIM (2FF) physical slot.

Two hardware versions carry eSIM:

  • RUT200 31**** – Europe, Australia, Asia-Pacific (order codes RUT200310000 and RUT200311030)
  • RUT200 34**** – EMEA, Thailand, Australia, New Zealand (order codes RUT200340000 and RUT200343000 – the latter being the UK PSU variant)

The eUICC supports up to seven stored profiles. Band coverage on both variants includes LTE FDD B1, B3, B5, B7, B8, B20, B28 – the full set required for UK operator coverage.

For those buying in the UK, the routerstore.com product page at routerstore.com/product/rut200-esim-4g-router/ covers the RUT200343000 as the standard UK SKU.


The Implementation: SGP.22 + Bootstrap + RMS

The RUT200 eSIM is built on SGP.22, with SGP.23 and SGP.24 compliance for technical specification and conformance testing respectively. A TPM 2.0 security chip handles the cryptographic requirements. This is a properly certified implementation, not a cut-down version of the standard.

Three components work together to make it useful in practice:

The SGP.22 eUICC. Standard consumer eSIM architecture. Profile downloads from an SM-DP+ server. Device-initiated pull model. Up to seven profiles stored simultaneously with one active. Manually triggered or policy-driven profile switching via RutOS.

The bootstrap profile. The device ships with a pre-loaded bootstrap profile on the eUICC – sufficient connectivity to reach the SM-DP+ provisioning server and pull down an operational profile without a physical SIM in the device. This solves the cold-start problem directly. For a detailed treatment of why bootstrap implementation matters and what can go wrong, see the eSIM Bootstrap Issues deep dive on this site, and the Teltonika and Tele2 bootstrap page which covers Teltonika’s specific bootstrap provider relationship.

Teltonika RMS. The Remote Management System that underpins the entire Teltonika router portfolio. For eSIM devices, RMS provides centralised profile management across deployed fleets – switching active profiles, triggering downloads, monitoring SIM status, responding to connectivity events – all without site access.

This third component is where the implementation becomes genuinely interesting from a standards perspective.


Where SGP.22 + RMS Meets SGP.32 in Practice

The standard critique of SGP.22 in IoT contexts is fair: the device-initiated pull model assumes the device can be reached and instructed to initiate a profile change. For constrained devices – NB-IoT sensors in deep sleep, low-power meters on coin cells, anything where a persistent IP connection is not guaranteed – this is a real architectural limitation. SGP.32 inverts this with a server-push model via the eIM, specifically designed for devices that cannot maintain a TLS session to an SM-DP+ server.

How the RUT200 eSIM provisions and manages profiles across two phases

Teltonika RUT200 eSIM: two-phase architecture Phase 1 shows initial provisioning from RUT200 with bootstrap profile through SM-DP+ server to operational profile. Phase 2 shows ongoing management from Teltonika RMS to the RUT200 fleet resulting in a remote profile switch. Phase 1 – initial provisioning (one-time) RUT200 eSIM SGP.22 + bootstrap profile SM-DP+ server Profile repository Profile delivered Operational profile Phase 2 – ongoing fleet management (Teltonika RMS) Teltonika RMS Fleet dashboard RUT200 fleet Remote profile switch Profile switched No site visit needed Physical SIM slot (2FF) remains active as fallback throughout both phases

SGP.32 native vs SGP.22 + RMS: matching the standard to the device type

SGP.32 native vs SGP.22 + RMS comparison Two cards comparing SGP.32 native, designed for constrained IoT sensors and NB-IoT and LTE-M devices, against SGP.22 plus RMS, designed for powered 4G routers with persistent IP connectivity. The RUT200 eSIM fits the SGP.22 plus RMS column. SGP.32 native Server-initiated push (eIM) NB-IoT and LTE-M support No user interface required eIM portable between platforms Constrained sensor use case vs SGP.22 + RMS Device pull + RMS command 4G LTE – full IP stack RutOS WebUI and fleet tools Wide operator compatibility Powered 4G router use case RUT200 eSIM fits here

For deployments moving toward native SGP.32 eIM management – whether as a next step beyond SGP.22 routers or for a new fleet of constrained IoT devices – eSIM IoT Manager provides a unified eIM platform for enterprise fleet control, currently in early access. For a broader independent reference across IoT connectivity, SIM selection, hardware and network architecture in the UK ecosystem, see IoT Index.

But that critique applies differently depending on what the device actually is.

The RUT200 is a permanently powered 4G router with a full IP stack, persistent RMS connectivity, and a management interface. The “device cannot initiate a profile change” problem does not exist here. When RMS instructs the device to switch profiles, it does so. The practical difference between that and a native SGP.32 server-push operation is, in this context, marginal.

Teltonika’s own position is clear on this: SGP.22 with RMS delivers wide compatibility plus centralised remote control, combining the strengths of both approaches. For the RUT200 use case, that is not marketing language – it is an accurate description of the architecture.

The table below maps the key SGP.32 capabilities against what SGP.22 plus RMS delivers on the RUT200:

CapabilitySGP.32 NativeRUT200 SGP.22 + RMS
Remote profile switch without site accessYes – server push via eIMYes – via RMS remote command
No physical SIM required at deploymentYes – bootstrap/eIMYes – bootstrap profile
Fleet-scale profile management dashboardYes – eIM platformYes – Teltonika RMS
Server-initiated push (no device action)YesNo – device-initiated pull
Constrained network support (NB-IoT, LTE-M, CoAP)YesNo – 4G Cat 4 only
eIM portability (change management platform)YesNo – tied to RMS
SM-DP+ compatibilityYesYes
TPM hardware securityVariesYes – TPM 2.0

The gaps are real. Server-initiated push without any device-side action, operation on constrained NB-IoT and LTE-M links, and eIM portability are genuine SGP.32 advantages that the RUT200 does not replicate. For a 4G router on permanent power, none of those gaps matter to the deployer.


What This Tells Us About Where the Market Is

The RUT200 eSIM is useful evidence in a broader argument about the eSIM hardware transition.

SGP.32 hardware is arriving. Certified modules are shipping, GSMA projections put SGP.32 at 70% of IoT eSIM profile downloads by 2029, and the eSIM Hardware Guide on this site covers the module and device landscape. But the transition is not a sudden switch. The majority of devices deploying into the field right now – and for the next several years – will carry SGP.22 eUICCs.

The important distinction is not SGP.22 versus SGP.32. It is SGP.22 implemented properly versus SGP.22 implemented poorly. A bootstrap profile that does not work in weak coverage, a management layer with no fleet capability, a hardware security approach that does not meet enterprise requirements – these are the real failure modes in the current market, and they are SGP.22 failures, not SGP.22-versus-SGP.32 failures.

What Teltonika has built with the RUT200 eSIM is the SGP.22 implementation done correctly: certified compliance, TPM 2.0 security, genuine bootstrap capability, and fleet-grade remote management via RMS. For its target application – industrial 4G router deployments where physical SIM management is the problem to be solved – that is the right answer.

The eSIM Hardware Guide and How OEMs Add eSIM pages on this site cover the broader landscape of how manufacturers are approaching eSIM integration. The RUT200 is a useful reference point at the accessible end of that spectrum.


Who Should Be Looking at the RUT200 eSIM

Deployers with physically inaccessible router installations. CCTV in traffic cabinets, routers in substations, equipment in locked plant rooms – anywhere a SIM swap requires specialist access. The RUT200 eSIM turns a field operation into a remote RMS action.

High-volume cost-sensitive deployments. The RUT200 is the entry tier of Teltonika’s eSIM router range. If the deployment needs industrial 4G router capability with eSIM management and budget is a constraint, this is the relevant SKU.

Deployments with existing RutOS infrastructure. Organisations already running Teltonika fleets on RMS gain eSIM capability without adding a new management platform. The learning curve is minimal.

Deployments that need SGP.22 ecosystem compatibility. Because SGP.22 SM-DP+ infrastructure is the most widely deployed in the industry, operator and MVNO profile support is broad. If the connectivity provider supports SGP.22 provisioning, the RUT200 eSIM will work with it.


Who Should Look at Native SGP.32 Instead

It is worth being direct about the cases where the RUT200 eSIM is not the right answer.

If the deployment involves constrained devices – NB-IoT sensors, LTE-M trackers, low-power meters – then SGP.32 native hardware is the correct target. The SGP.32 vs SGP.22 comparison covers the architectural reasons in detail. The RUT200 is a 4G Cat 4 router; the SGP.32 advantages around constrained network operation simply do not apply to it.

If long-term management platform independence matters – the ability to move the eSIM management function to a different provider without touching the hardware – then eIM portability is a meaningful consideration. SGP.22 with RMS ties the device to Teltonika’s management ecosystem. For some enterprise deployments, that dependency is a commercial risk worth weighing.

If the procurement decision involves a TCO analysis across device lifecycle, the SGP.32 advantages around operator switching and profile management at scale become more significant over five to ten year horizons.


A Note on Bootstrap

The bootstrap provider relationship for Teltonika eSIM devices is covered in detail in the Teltonika and Tele2 page on this site. The RUT200 eSIM uses the same bootstrap infrastructure as other eSIM-capable devices in the Teltonika range. Understanding who provides the bootstrap profile, what coverage it offers, and what happens when the bootstrap profile itself cannot get online is important pre-deployment knowledge – particularly for remote or poorly-served locations. The Choose a Bootstrap Provider guide is the relevant starting point.


Summary

The Teltonika RUT200 eSIM is not a SGP.32 device. It is a SGP.22 device with a properly implemented bootstrap profile and Teltonika RMS as the remote management layer. For the application it targets – industrial 4G router deployments where physical SIM management is the operational problem – the combination delivers most of what eSIM is supposed to provide, at the accessible end of the Teltonika price range.

It is a useful marker of where the market currently sits: SGP.32 is the standard the industry is transitioning toward, but SGP.22 implemented correctly is what most deployers are actually using. The RUT200 eSIM represents the better end of that current reality.

For the full comparison between the standards, see SGP.32 vs SGP.02 vs SGP.22. For hardware procurement guidance, the What to Ask Your Hardware Provider checklist applies directly to conversations with router suppliers about eSIM variant availability and bootstrap support.

For deployments moving toward native SGP.32 eIM management – whether as a next step beyond SGP.22 routers or for a new fleet of constrained IoT devices – eSIM IoT Manager provides a unified eIM platform for enterprise fleet control, currently in early access. For a broader independent reference across IoT connectivity, SIM selection, hardware and network architecture in the UK ecosystem, see IoT Index.

The bootstrap provider behind Teltonika’s eSIM devices is Tele2 IoT. For detail on how that commercial relationship works, what the 10MB bootstrap window covers, and what it means for deployments in low-coverage locations, see SGP.32 in Practice: The Teltonika and Tele2 Bootstrap Partnership.


The RUT200 eSIM is available from routerstore.com. For the broader eUICC and eSIM context, see euicc.co.uk.


euicc.co.uk

The UK authority on eSIM and eUICC - consumer, M2M and IoT standards explained