Understanding eSIM and SGP22 vs SGP32 and Robustel.
If you’ve worked with IoT kit for any length of time, you’ll know that the SIM card is often the least exciting part of a deployment but the most annoying thing to deal with later. Networks change, roaming rules tighten, equipment stays in the field far longer than the contract you signed, and suddenly a tiny piece of plastic becomes a blocker.
Robustel’s work with Kigen aims to clear that headache. They’re not trying to lock anyone into a closed ecosystem. They’re trying to give manufacturers, integrators and end users a bit of breathing room. You keep the hardware you want. You keep your choice of network. You gain the flexibility to change operator without touching the device. And for once, the marketing actually matches what’s happening under the bonnet.
This is a breakdown of what Robustel are doing, what Kigen bring to the table, and why it matters for real IoT projects where the kit has to run for years with minimal fuss.
What the partnership actually delivers
Robustel have been building industrial routers and gateways for years, and they’re used in all the predictable places: energy sites, roadside cabinets, remote machinery, EV charging, transport and so on. Their collaboration with Kigen adds eSIM and eUICC capability in a way that doesn’t force you down a single-provider route. It simply gives you more options.
Kigen handle the secure eSIM software, profile management and the plumbing that makes remote provisioning work. Robustel add the industrial hardware, their operating system, and their fleet management platform, RCMS. The result is:
- Hardware that can download and run different operator profiles rather than being tied to a single SIM.
- A choice of using plastic eSIM cards for older devices, or embedded MFF2 chips on newer models.
- A clear migration path from traditional IoT SIM cards to eSIM without replacing entire fleets.
- Remote network changes without rolling a van or opening a cabinet.
No lock-in. No secret clauses. You can use the Kigen infrastructure to manage profiles, but you’re not married to Kigen for connectivity.
The part everyone cares about: retrofit
This is where it gets genuinely useful. Lots of IoT estates already have Robustel routers out in the field. Some will be in roadside boxes, some bolted to walls in energy sites or stuck under digital signage panels. The last thing anyone wants is to rip them out just to upgrade the SIM strategy.
Robustel’s retrofit option means you can use a plastic eSIM card in the existing SIM slot. The hardware doesn’t need redesigning. The installation doesn’t need re-running. The eSIM card acts as a full eUICC with support for multiple profiles and remote switching.
For many companies that alone is worth the upgrade. You can modernise your connectivity without touching the physical device. And any new deployments can move to the embedded version which is safer, tougher and removed from vibration, moisture and corrosion risk.
Why this actually solves real problems
A lot of eSIM marketing feels like buzzwords stitched together. This one doesn’t. Here are the problems it directly tackles.
Long equipment life
Industrial equipment usually lasts far longer than the SIM contract. When the network changes, you currently have to send someone out. With eSIM you don’t.
Harsh environments
SIM trays corrode, vibrate loose and generally misbehave. An embedded MFF2 chip removes that risk entirely.
Roaming crackdowns
Permanent roaming restrictions are increasing. Switching operator profiles remotely lets you stay compliant and keep the equipment online.
Multi-network fallback
A single SIM can now hold multiple profiles. If the primary network is weak, you can switch to another without visiting site.
Global rollouts
Instead of ordering country-specific variants of the same device, you can stock one SKU and assign operator profiles per country later.
It simplifies purchasing, simplifies deployment and makes long-term support less painful.
IoT SIM cards in an eSIM world
Physical IoT SIM cards aren’t disappearing any time soon. They’re still ideal for trials, temporary deployments or situations where the engineering team wants something familiar. They also integrate cleanly into private APNs, VPNs and fixed IP setups.
But once you scale or move into multi-country projects, eSIM becomes the smarter option. It gives you the flexibility to:
- Host multiple operator profiles on the same device.
- Swap profiles remotely when tariffs or conditions change.
- Keep using your preferred IoT SIM provider without tying the hardware to them.
- Remove the mechanical weak point of a SIM tray.
The important bit here is that Robustel haven’t forced you to choose one or the other. Use your existing IoT SIM cards now and switch to eSIM at your own pace.
Real-world applications
There’s no shortage of places where this setup makes sense. Here are a few examples.
Energy and utilities
Water treatment plants, remote pumps, substations and solar farms often rely on single-operator SIMs chosen years earlier. With eSIM you can update the profile when the local network gets patchy, without touching the site.
Smart city infrastructure
CCTV poles, EV chargers, ANPR systems and traffic cabinets usually sit in difficult-to-reach locations and suffer from harsh conditions. Embedded eSIM eliminates the tray and lets councils switch operators across hundreds of devices from one console.
Transport and logistics
For fleets that travel across borders, eSIM avoids the usual roaming headaches. Operators can be changed regionally without swapping hardware.
Industrial and manufacturing
Remote machinery in factories, ports, mines or rail environments normally stays in place for a decade or more. eSIM turns connectivity from a fixed choice into a flexible one.
What you should check before moving to eSIM
If you’re planning to roll this out properly, here are the sensible housekeeping steps:
- Check which Robustel models you already use
Most of the current range supports eSIM when using a plastic card. Newer versions offer embedded MFF2. - Check firmware versions
Make sure your models support the eSIM profile manager and remote provisioning. - Decide your connectivity strategy
Do you need multi-network fallback, or a single primary operator? Will profiles be the same across all regions? - Plan your migration
Use plastic eSIM cards for the existing fleet and adopt embedded eSIM in your next hardware batch. - Test profile switching
Make sure your chosen IoT SIM provider or operator supports the provisioning workflows you need.
A cleaner way to manage long-term IoT
The Robustel and Kigen partnership isn’t trying to reinvent the industry. It’s trying to get rid of the everyday friction that slows projects down. The core idea is simple: the hardware should last, the operator can change, and the user shouldn’t be locked into anyone’s ecosystem.
You can keep your current IoT SIM setup, slowly adopt eSIM, or go fully embedded across new deployments. The important thing is that you get genuine choice without the usual strings attached. It’s rare to see a vendor partnership that doesn’t come with quiet lock-in. This one feels refreshingly open.
Technical Deep Dive: Understanding SGP22, SGP32, IPA, eIM and the Modern eSIM Architecture
The world of eSIM is going through one of its biggest shifts since embedded SIMs first appeared in industrial and IoT hardware. The established SGP22 system is slowly giving way to the more flexible SGP32 architecture, which promises simpler provisioning, lighter infrastructure and wider hardware compatibility.
A lot of confusion comes from how these two standards relate, whether older eSIM chips can be upgraded, and what role the new components such as IPAd, IPAe and eIM actually play. This guide breaks it down in a clear, practical way.
SGP22 vs SGP32: What has changed
SGP22 has been used for years in M2M and industrial deployments. It relies on several heavy backend components, including the SM-SR and SM-DP+, and places most of the intelligence inside the eSIM chip itself.
SGP32 simplifies the whole process. It removes some legacy components, reduces the overhead on the eSIM chip and shifts part of the logic into the device software.
Key differences
- SGP22 is chip-centric and relies on multiple tightly-coupled backend systems.
- SGP32 is lighter, more flexible and designed for large-scale IoT deployments.
- SGP32 can work with or without an embedded eSIM chip.
- SGP32 replaces the SM-SR with a simpler and more efficient workflow.
Can an SGP22 eSIM be upgraded to SGP32?
The short answer is: sometimes, but not always.
Whether an existing eSIM can support SGP32 depends on:
- The eUICC chip hardware
Some chips include the cryptographic and memory features required for SGP32. Older ones do not. - The eUICC operating system
If the OS supports SGP32 or can be updated by the vendor, the chip may become compliant. - Device firmware support
The device must support the new message flows, profiles and IPA behaviour. - Backend support
The provisioning servers must speak SGP32 and offer the updated workflows.
If all four pieces are compatible, an SGP22 device can transition to SGP32. If not, it will stay on SGP22 for its entire life.
This uncertainty is why the industry is seeing a slow transition rather than a rapid switch.
IPAd and IPAe: The biggest shift in SGP32
One of the most important parts of the new SGP32 architecture is the IOT Profile Assistant, or IPA.
It comes in two forms.
IPAe
- Lives inside the eUICC chip.
- Handles profile installation, deletion and switching.
- This is the traditional approach inherited from SGP22.
IPAd
- Runs in the device software instead of inside the chip.
- Manages profile downloads, activation and switching.
- Does not require a physical embedded eSIM chip.
- Enables eSIM provisioning on devices that previously relied only on removable SIM cards.
IPAd is a major step forward because it gives manufacturers more freedom. Devices can participate in SGP32 provisioning even if they don’t include a soldered eSIM chip.
Why SM-DP+ and IPA alone are not enough
SM-DP+ and IPA each have clear roles, but neither can manage a large deployment by themselves.
What SM-DP+ does
- Stores eSIM profiles
- Encrypts them
- Delivers them securely when requested
It only responds when a device asks for a profile. It does not decide when a device should switch profiles or manage fleets.
What IPA does
IPAd and IPAe handle local tasks:
- requesting profiles
- installing them
- switching between them
- deleting them
IPA acts on a single device. It has no awareness of how hundreds or thousands of other devices should behave.
The role of eIM
eIM fills the orchestration gap and ties the whole ecosystem together.
What eIM handles
- Assigning profiles to devices at scale
- Coordinating fleet-wide operator changes
- Applying rules such as regional compliance
- Managing fallback behaviour
- Handling security and certificate management
- Automating profile delivery workflows
- Maintaining audit trails and lifecycle histories
Without eIM, every device would have to be managed manually. SM-DP+ and IPA simply do not have the awareness or control to manage large deployments on their own.
A simple way to picture the roles:
- SM-DP+ stores and delivers profiles
- IPA installs and controls profiles on the device
- eIM decides what should happen across the entire fleet
Why the shift to SGP32 matters for IoT
SGP32 introduces several practical benefits:
- Simpler provisioning flows
- More flexible device compatibility
- Less reliance on specialised embedded hardware
- Faster onboarding for large-scale IoT fleets
- Reduced complexity for operators and connectivity providers
- Easier regional profile switching
- Better support for devices that need long-term lifecycle management
Most importantly, SGP32 allows eSIM capability to be built into far more devices, even those without a dedicated eSIM chip.
This is a significant change for long-life IoT deployments where connectivity may need to adapt over many years.
FAQ
1. Is every SGP22 device upgradeable to SGP32?
No. Only devices with compatible eUICC chips and firmware can be upgraded. Many older chips will remain SGP22-only.
2. Does SGP32 remove the need for embedded eSIM chips?
Not always, but it allows devices to support eSIM provisioning through software alone using IPAd.
3. What does eIM actually control?
It handles fleet orchestration, automation, policy enforcement, security management and bulk profile changes.
4. Is SM-DP+ still required in SGP32?
Yes. SM-DP+ continues to store and deliver encrypted profiles, but its role becomes simpler.
5. How long will SGP22 and SGP32 coexist?
Likely for several years. The industry is transitioning gradually because not all hardware and backend systems are ready.
Comprehensive eSIM Glossary (SGP22, SGP32, IPA, eIM and Related Terms)
SGP22
The established M2M eSIM architecture originally designed for industrial and automotive use. Heavier, more rigid, and reliant on multiple backend systems such as SM-SR and SM-DP+.
SGP32
The newer IoT eSIM architecture designed to simplify provisioning, reduce infrastructure complexity and widen device compatibility. Removes SM-SR, introduces IPA, and allows eSIM provisioning even on devices without embedded eUICCs.
eSIM
A programmable SIM environment that can download, store and switch network operator profiles remotely, without needing a physical SIM swap.
eUICC
The secure element that stores eSIM profiles. This can be a soldered embedded chip or a removable SIM card containing eUICC software.
Embedded eSIM (MFF2)
A soldered eSIM chip designed for long-term durability, improved environmental tolerance, and reduced mechanical failure. Uses the MFF2 form factor.
Plastic eSIM (SIM-card form)
A removable SIM-shaped card that contains eUICC functionality. Used to enable eSIM provisioning in devices not originally designed with embedded eSIM hardware.
Profile
A digital package that contains operator credentials, authentication keys, network access rules and lifecycle metadata. A device may store multiple profiles and switch between them.
Bootstrap Profile
A minimal, generic profile that provides initial connectivity so the device can fetch its operational profile during onboarding.
Operational Profile
The primary profile used for live connectivity once the device is deployed.
IPA Components (SGP32)
IPA
Short for IOT Profile Assistant. This is the component responsible for managing profile downloads, installation, switching and deletion under SGP32.
IPAd
The device-based implementation of IPA. Runs in the device’s operating system. Handles profile management without requiring an embedded eUICC chip. One of the biggest innovations in SGP32.
IPAe
The embedded implementation. Lives inside the eUICC chip itself. Executes local profile operations through hardware-based security.
IPA Client
The specific software module inside IPAd or IPAe that communicates with provisioning servers, requests profiles and performs installation.
IPA Policies
Rules stored either on the device or assigned through backend systems that determine how and when profiles should be activated, switched or deleted.
Provisioning Backend (SGP22 and SGP32)
SM-DP+ (Subscription Manager – Data Preparation)
The secure server that stores, encrypts and delivers eSIM profiles to devices. Present in both SGP22 and SGP32.
SM-SR (Subscription Manager – Secure Routing)
Used only in SGP22. Manages profile state on each device (enabled, disabled, deleted). Removed entirely in SGP32.
Discovery Service
A service that helps devices find the correct SM-DP+ server during initial activation, especially when the bootstrap profile has limited routing information.
Profile Delivery Session
A secure channel opened between the device and SM-DP+ to download and install a profile.
eIM and Fleet Management
eIM (eSIM IoT Manager)
The orchestration layer introduced for IoT-scale deployments. Coordinates profile delivery, applies automation, enforces policies and manages security at fleet scale.
Policy Engine
Part of eIM that controls decisions such as:
- which devices receive which profiles
- regional operator rules
- fallback conditions
- onboarding behaviour
Certificate Manager
The section of eIM responsible for authenticating devices, securing provisioning sessions and managing cryptographic lifecycles.
Fleet Provisioning
The process of assigning profiles to large groups of devices automatically using predefined rules.
Lifecycle Management
A structured approach to handling profile states across the device estate. Includes activation, suspension, replacement, removal and recycling.
Connectivity Concepts
Multi-IMSI
A strategy where multiple IMSIs (network identities) are stored in a single profile, enabling on-device switching for roaming or fallback without profile replacement.
Multi-Profile
When a device stores several full operator profiles simultaneously. Only one can be active, but switching is fast and does not require a new download.
Local Profile
A profile tied to a regional operator. Useful for addressing permanent roaming restrictions.
Roaming Profile
A profile that uses a global or multi-network arrangement, often suited for mobile assets or multi-country deployments.
Fallback Profile
A profile reserved for fallback if the primary operator fails. Often a bootstrap or neutral roaming profile.
Device-Side Architecture
Modem Identity
The network identity presented by the modem based on whichever profile is active.
Profile Switch Event
The moment the device transitions from one operator profile to another. May trigger a modem reset or network re-registration.
Profile Container
The dedicated secure storage area on the eUICC where individual profiles are held.
Secure Channel Establishment
The cryptographic handshake between the device and SM-DP+ used to download a profile safely.
Security Terms
EAL Certification
Security certification level (Common Criteria) used for eUICC hardware. Determines the chip’s tamper resistance.
Key Ladder
A secure hardware mechanism used inside eUICCs to protect cryptographic keys.
Root of Trust
The foundation of security in the device, combining hardware, firmware and cryptographic identity.
Attestation
A secure method for verifying a device’s integrity before allowing profile downloads or switching.
Standards and Governance
GSMA
The global body responsible for defining the SGP22 and SGP32 eSIM standards.
RSP (Remote SIM Provisioning)
The umbrella term for the overall process of downloading, activating and managing eSIM profiles.
Interoperability Testing
Checks performed to ensure a device, eUICC, backend and provisioning flows all comply with the same GSMA standard.