SGP.32 in Practice: The Teltonika and Tele2 Bootstrap Partnership

Why This Partnership Matters

The collaboration between Teltonika Networks and Tele2 IoT is one of the clearest working examples available in the UK and European market of how eSIM bootstrap is supposed to work in practice. It demonstrates the hardware-to-network handshake at an architectural level that most eSIM guides describe only abstractly.

Understanding this partnership is useful not just for Teltonika customers but for anyone trying to understand how the bootstrap provisioning model works in a real commercial deployment.

What Tele2 IoT Provides

Tele2 IoT is one of the more aggressive players in the SGP.32 connectivity space. Their role in the Teltonika partnership is to provide the bootstrap profile – the pre-loaded SIM credential that ships inside every eSIM-capable Teltonika router from the factory.

The Tele2 bootstrap profile provides global roaming connectivity through Tele2 IoT network agreements. When a Teltonika router powers on for the first time anywhere in the world, it connects to a Tele2 IoT network (or a roaming partner network) using this bootstrap credential.

Crucially, the Tele2 bootstrap is a managed bootstrap rather than a static one. It includes fallback logic and the ability to reach Teltonika RMS even before the operational profile has been downloaded. This means an engineer can see the device in the management platform from the moment it powers on, not just after it has successfully provisioned.

The 10MB Bootstrap: What It Covers and What It Does Not

The Tele2 bootstrap profile on Teltonika devices allows approximately 10MB of data, restricted to the following traffic types:

• DNS resolution (to find the SM-DP+ and RMS server addresses)
• DHCP (to obtain an IP address on the bootstrap network)
• HTTPS connections to the SM-DP+ server (to download the operational profile)
• Connections to Teltonika RMS (to allow remote management during provisioning)

All other traffic is blocked. The device cannot browse the internet, send operational data, or reach its own management systems on the bootstrap profile. This restriction prevents the bootstrap data from being consumed by normal device operations and ensures the 10MB is available for its intended purpose: downloading the operational profile.

A typical SGP.32 operational profile download consumes approximately 1-3MB. This leaves comfortable headroom within the 10MB allowance for retry attempts if the first download fails.

The Bootstrap Validity Period

The Tele2 bootstrap profile on Teltonika devices is valid for one year from the manufacturing date of the router. After one year, the bootstrap credential expires and the device can no longer use it to initiate a new provisioning sequence.

This is the primary operational risk in the Teltonika deployment model. A router that sits in a warehouse for eleven months before deployment has approximately one month of bootstrap validity remaining. If the deployment is delayed further, or if the operational profile download fails and needs to be retried after the validity period expires, the device may require physical intervention to recover.

Teltonika addresses this by providing a mechanism through RMS to re-issue the bootstrap activation command while the bootstrap is still valid. For devices that are already online and have successfully provisioned, this is not a concern. For devices that have connected but not yet completed provisioning, RMS provides a recovery path without requiring a site visit.

The RMS Layer: Where the eIM Concept Applies

The Tele2 bootstrap solves the “first 10 minutes” problem – getting the device connected enough to download its operational profile. But the question the Gemini analysis raises is the right one: who manages the next 10 years?

Teltonika RMS acts as the management layer above the SGP.22 eSIM architecture on their devices. It adds the server-initiated profile management capability that SGP.32 provides natively but that SGP.22 does not include. An administrator with RMS access can push a profile change to a fleet of Teltonika routers without visiting a single device.

This is not SGP.32. It does not use the eIM architecture, CoAP transport, or asynchronous management defined in the SGP.32 specification. But it delivers comparable operational outcomes for the router and gateway use case, where devices are always-on and well-connected.

The Missing Layer: What a Standalone eIM Would Add

The Teltonika RMS approach is a closed system – it works within the Teltonika ecosystem. A standalone eIM platform, operating under the SGP.32 specification, would add capabilities that RMS does not provide:

• Hardware-agnostic management: the same eIM could manage Teltonika routers, Milesight gateways, Quectel modules, and any other SGP.32 certified hardware from a single console
• Genuine multi-operator profile management without vendor-specific integration work
• eIM portability: the ability to migrate device management between platforms without hardware replacement
• Native support for constrained NB-IoT and LTE-M devices that RMS cannot manage

This is precisely the gap that a well-built eIM management portal – whether commercial or built around the esimiotmanager.com concept – would fill. The Teltonika and Tele2 partnership demonstrates the demand. The absence of a clean, hardware-agnostic eIM interface for mid-market deployments demonstrates the opportunity.

For a full technical explanation of how bootstrap works, see eSIM Bootstrap Issues. For a buyer guide to evaluating bootstrap providers, see How to Choose a Bootstrap Provider.