SGP.32 eSIM: Local Profiles Cut Roaming Risk in IoT

SGP.32 is the GSMA eSIM IoT specification that lets one eUICC hold several operator profiles and lets an enterprise manage them remotely. That gives global IoT fleets a way to swap in local carrier profiles, switch networks automatically and control the whole connectivity lifecycle from one platform, though only where carriers, regulation and coverage allow it.

Key takeaways

SGP.32 turns the eSIM into a remotely managed asset, so you can change carriers without touching the device.
Local profiles can cut reliance on permanent roaming, which some markets restrict.
Automated switching and fallback rules improve reliability, but only if you design and test them.
Meters, vehicles, industrial machines and battery devices each need different policies.
SGP.32 isn't automatically cheaper. Track measurable KPIs to prove the value.

SGP.32 turns the eSIM into a remotely managed connectivity asset

SGP.32 targets devices that are network-constrained, unattended or spread across several countries, and that have no user interface. The GSMA catalogue lists v1.2 as active (GSMA, eSIM Consumer and IoT Specifications). Consumer eSIM flows assume someone scans a QR code. IoT devices can't rely on that.

A close-up of a tiny embedded SIM chip on a circuit board inside an opened industrial IoT module, softly lit, with faint glowing blue light trails radiating outward toward distant silhouettes of cell towers across a wide landscape at dusk.

Because one eUICC holds multiple profiles, you can ship a single SKU and still offer multiple local connectivity options. I see three mechanisms behind this:

Remotely managed local profiles.
Automated switching.
Centralized lifecycle control through an eSIM IoT Remote Manager (eIM).

The architecture has three parts. The IoT Profile Assistant (IPA) sits on or near the device. The eIM orchestrates fleet operations. The SM-DP+ prepares profiles for encrypted, authenticated download.

Keep one limit in mind. SGP.32 is an enabling standard. It doesn't remove the need for operator agreements, regulatory review or adequate radio coverage.

Local profiles reduce dependence on permanent roaming

Permanent roaming causes trouble. Some markets restrict it, require local registration or favor domestic subscriptions. Availability can also shift with commercial agreements, network shutdowns or policy changes.

Here's how the remote flow works:

The device ships with a bootstrap or preloaded profile.
The eIM selects a target profile.
The SM-DP+ delivers it securely.
The profile is enabled remotely.
The old profile stays, gets disabled or gets deleted, depending on your policy.

Compare that with the alternatives. Country-specific physical SIMs force you to manage multiple hardware variants. One SGP.32 hardware SKU simplifies inventory and production. Global roaming SIMs keep hardware simple but leave you exposed to roaming limits. Vodafone IoT notes that SGP.32 can shift devices onto domestic subscriptions (Vodafone IoT, How to implement the new eSIM SGP.32 standard).

Localization can bring local pricing, domestic operator relationships and faster market entry. I'd add one caveat. You still need eligible profiles, authorization and compatible hardware in each country.

Automated switching and eIM control improve reliability

A well-designed deployment reacts to events instead of waiting for a technician. I'd consider these switching triggers:

A country change.
Repeated attach failures or coverage loss.
An operator outage.
A roaming-policy breach.
A cost threshold.
A planned carrier migration.

The reliability sequence is simple. The device uses its preferred local profile. It detects a failure and applies a fallback policy. It reverts to a bootstrap or alternate profile and reports to the central platform. Onomondo describes this pattern: automatic local-profile selection, fallback to a broader multi-network profile and remote changes through fleet management (Onomondo, SGP.32 eSIM IoT).

Don't confuse multi-profile eSIM with multi-IMSI connectivity. They're related but not identical. Switching also isn't instant. Modem behavior, reattachment, download access and retry or rollback logic all affect the outcome.

The eIM acts as your fleet control plane. It can inventory, authorize, install, enable, disable, switch and delete profiles. It applies policies by region or customer and handles decommissioning. Changes roll out in bulk instead of through technician visits.

What it means for meters, vehicles, industrial equipment and battery devices

Each application stresses connectivity in a different way. I'd match the policy to the device.

A utility technician's gloved hand closing a weatherproof electricity smart-meter cabinet on a brick wall in a quiet European street, while a modern electric car and a distant wind turbine appear in the soft morning background.

Smart meters: These long-life devices are hard to reach and send small, periodic transmissions. They can receive local profiles after installation, take part in bulk migrations and fall back during outages. Check LTE-M or NB-IoT support and in-building coverage first.
Connected vehicles: Cross-border telematics, diagnostics and updates benefit from location- or market-driven profile changes. Vodafone IoT cites large multi-country uses such as automotive. Safety-critical functions need separately validated resilience, because profile switching alone is no guarantee.
Industrial equipment: Remote or relocated machinery can stay in service for 10+ years. It gains remote commissioning, carrier migration without SIM replacement and secure decommissioning at sale or retirement.
Battery-powered devices: Attach time, signaling and retries drain power. Schedule downloads in maintenance windows and use retry backoff. Keep a known-good fallback and avoid switching loops.

An aerial view of a remote industrial site at golden hour with a mining truck, solar panels and a pump station, each topped with a small antenna, arranged across rugged terrain and connected by faint, abstract light arcs in the sky.

For low-power gear, ask vendors for hard numbers. Semtech markets a dual-profile "PowerSave" eSIM meant to optimize attach time (Semtech, SGP.32 Multi-Profile eSIM for Global IoT Deployments). Treat that as a vendor claim, not an industry result. Request energy per attach, energy per profile download and behavior when a download gets interrupted.

Limits, security and the metrics that prove value

Several dependencies decide whether this works in practice:

Carrier profile availability.
Local regulation.
A certified eUICC and modem.
eIM and SM-DP+ interoperability.
A preserved bootstrap path.

Switching can briefly interrupt registration. Plan for that gap.

Local profiles also add work. You'll manage more subscriptions, more complex billing, more operator relationships and more testing. Total cost of ownership depends on hardware, platform fees, data, field visits, downtime and compliance. SGP.32 isn't automatically cheaper.

Flexibility raises the stakes on governance. I'd put these controls in place:

Mutual authentication.
Role-based access.
Approval workflows for mass changes.
Audit logs.
Rollback and profile revocation.

Decide early who owns the eIM and who authorizes carrier switches.

Then measure results. Track these KPIs:

Connectivity availability.
Registration and activation success.
Mean time to recover.
Fallback frequency.
Remote-operation rate.
Truck rolls avoided.
Battery impact.
Data cost per device.

Label every figure clearly. Separate published facts, illustrative calculations and named customer results. My rule is simple: resilience is an architectural outcome, not an automatic feature. Tested fallback rules, monitoring and operational response create it.