The eSIM Readiness Checklist: Is Your IoT Deployment Ready for eUICC?

Everyone in IoT is talking about eSIM. For OEMs, that conversation often starts with the promise of greater flexibility: fewer physical SIM swaps, easier multi-carrier deployments, streamlined global rollouts, and more control over connectivity after devices leave the factory.

But eSIM readiness is not as simple as choosing an embedded SIM form factor or asking whether a provider “supports eSIM.” A successful eSIM strategy depends on a broader set of decisions across device hardware, eUICC capability, carrier certification, remote SIM provisioning, profile orchestration, permanent roaming, data sovereignty, and post-launch connectivity management.

A device may contain an embedded SIM but lack true remote profile management. A SIM may support multiple profiles, but the device may not be certified on the carrier network it needs to use. A global deployment may work during a pilot, then face roaming restrictions or data-routing concerns once devices are permanently installed in the field.

This checklist is designed to help IoT product managers, engineering teams, and operations leaders evaluate whether their deployment is actually ready for eUICC. Use these questions to identify the technical, operational, and commercial gaps that could later hinder your eSIM strategy.

eSIM, eUICC, and embedded SIM: What’s the difference?

Terms like “eSIM,” “embedded SIM,” and “eUICC” are often used interchangeably. In IoT deployments, however, these terms refer to distinctly different things.

An embedded SIM often refers to the physical SIM form factor. For example, an MFF2 SIM is soldered directly onto the device board instead of inserted into a removable SIM slot. That can be valuable for IoT devices deployed in rugged, remote, mobile, or sealed environments since there is no tray that can be damaged or require manual replacement. However, an embedded SIM form factor does not automatically mean the device can remotely switch carrier profiles.

eUICC (or embedded Universal Integrated Circuit Card), refers to the SIM technology that enables remote profile management. With eUICC, multiple carrier profiles can be downloaded, stored, and enabled without physically accessing the device. In an IoT context, that can give OEMs more flexibility over the full device lifecycle, especially when devices are deployed across diverse regions and multiple carriers.

These three terms all have semantic differences:

• An embedded SIM is SIM hardware that is directly soldered into the device.
• An eUICC supports remote carrier profile management and multiple downloadable profiles.
• An eSIM is often used as the broader market term, but it can refer to either the form factor, the remote provisioning capability, or both, depending on context.

Confusion over terms can lead to early wrong decisions. An OEM may choose a soldered SIM assuming it will support multi-carrier switching later, only to discover that the device cannot remotely manage profiles. Or a team may assume that “eSIM support” means the provider can orchestrate a global, multi-carrier IoT deployment when the actual implementation is much more limited.

When evaluating eSIMs, OEMs and enterprises need to ask themselves: Does the device support remote profile management through eUICC, and is the rest of the deployment architecture ready to use it?

What is GSMA SGP.32, and why does it matter for IoT?

SGP.32 is the GSMA’s technical specification for eSIM IoT. GSMA currently lists SGP.32 v1.3, published May 22, 2026, as an active eSIM IoT Technical Specification.

IoT devices are different from consumer devices. A smartphone user can scan a QR code, tap through an activation screen, and manually select a plan. IoT devices may not have a screen or keyboard, possess limited power, use intermittent bandwidth, or have no hands-on user after deployment.

SGP.32 was designed for the IoT device reality. GSMA describes the specification as covering remote provisioning and management of eUICCs in IoT devices that are network constrained and/or user-interface constrained.

How SGP.32 differs from earlier eSIM standards

Earlier eSIM standards were built for different device categories. SGP.02 was designed for M2M deployments, where remote provisioning was typically controlled through operator-managed infrastructure. SGP.22 was designed for consumer devices, where a user interface and user action are usually part of the activation flow. SGP.32 brings the model closer to what IoT fleets need: remote, scalable profile management for devices that may be deployed in large numbers without human interaction.

The standard also introduces a more flexible architecture for IoT profile orchestration. Instead of relying on older approaches that were not well suited for constrained IoT environments, SGP.32 introduces components that help manage remote profile operations across devices and fleets.

What the eIM and IPA do

Two key SGP.32 components matter for IoT OEMs: the eIM and the IPA.

The eIM, or eSIM IoT Remote Manager, manages the orchestration actions required for remote SIM provisioning. It can coordinate profile downloads, enable profiles, disable profiles, delete profiles, and support lifecycle operations across a fleet without physical SIM swaps or user intervention.

The IPA, or IoT Profile Assistant, is the device-side or SIM-side component that helps execute those instructions. It acts as an intermediary between the eUICC and the remote management infrastructure, allowing profile operations to happen without requiring a consumer-style local profile assistant or user interface.

In practical terms, this architecture helps make eSIM more usable for IoT. It supports remote profile management for devices that are installed in the field, sealed inside equipment, deployed across regions, or managed in fleets rather than one at a time.

However, not all SGP.32 eSIM solutions are designed equally. OEMs should ask providers what version, architecture, carrier profile access, and operational support they actually provide. While many connectivity providers claim to support eSIMs, they also must help you ensure that those eSIMs match your deployment and function optimally across your device’s actual lifecycle.

The eSIM readiness checklist for IoT deployments

eSIM readiness is a cross-functional assessment across engineering, product, operations, compliance, support, finance, and go-to-market strategy. Before design freeze or manufacturing, your team should be able to answer the following questions.

1. Is your device hardware eUICC-ready?

Can your device support the eUICC functionality your deployment requires? A device may have a soldered SIM, but that does not automatically mean it can store multiple carrier profiles or switch between them remotely. It may also support a given carrier profile on the SIM, but lack the required band support, antenna design, radio performance, or certification status to activate on the target network.

For IoT OEMs, this needs to be addressed at the module selection and device design stage, not after design freeze.

Ask:

• Does the device support an eUICC-capable SIM with multiple profile storage?
• Does the module operate on all required bands and frequencies for the target carriers?
• Is the device certified on those bands and frequencies, not merely compatible in theory?
• Is the device deployed in locations where physical SIM access is difficult, expensive, or impossible?

That last question often determines the business case. If a device will be installed in a vending machine, payment terminal, medical device, vehicle, security system, remote sensor, kiosk, or sealed industrial enclosure, physical SIM access may not be practical after launch. In those cases, eUICC can be the difference between efficient deployment control and field-service dependency.

2. Have you mapped your carrier certification path?

Certification planning should happen before manufacturing. A device can contain an eUICC. It can carry a valid carrier profile. It can use a module that technically supports the right LTE bands. But if the fully assembled device is not certified on the target carrier’s network, it may not be allowed to activate.

Band and frequency support

The device must support the specific bands and frequencies used by the carriers and regions you intend to serve. This should be confirmed during module selection, antenna design, and early engineering validation.

If the device is meant to support Verizon, AT&T, T-Mobile, or international carriers, do not assume one module choice automatically covers every activation path. Confirm which carriers matter, which bands they require, and whether the fully assembled device can meet performance expectations on those networks.

Carrier-specific certification requirements

Each carrier has its own certification process. Verizon’s Open Development program, for example, outlines a certification process that includes registering, submitting the device, certifying the device, and preparing for market. Verizon also lists Fast Track eligibility requirements such as using a Verizon-certified module, PTCRB or GCF certification, RF OTA testing on Verizon bands, FOTA reporting, and IoT security submission.

AT&T also offers IoT device certification and deployment services, noting that IoT devices need certification to operate on cellular networks and should be certified as fully assembled devices, not only at the chipset, module, or antenna level.

Ask:

• Which carriers need to certify the device?
• Are the module, antenna, firmware, and profile strategy aligned with certification requirements?
• Will different regions require different approvals?
• Does your connectivity partner provide certification guidance and direct carrier coordination?

The right partner can materially reduce risk. Zipit works directly with carrier teams and can help IoT OEMs understand the certification path before connectivity decisions become expensive to change.

3. Do you know where and how profiles will be provisioned?

Where will carrier profiles be loaded? At manufacturing or upon first activation? After the device reaches the customer? Later in the lifecycle when coverage, cost, or compliance requirements change?

A key issue is the “chicken-and-egg” problem of remote failover. If a device loses connectivity and does not already have a usable backup profile available locally, it may not be able to reach a provisioning server to download a replacement profile. A device that needs connectivity to fix its connectivity problem may already be offline.

For many IoT deployments, especially those with uptime or coverage sensitivity, pre-loading backup profiles locally on the SIM can create a stronger failover model. Instead of depending entirely on a live server connection at the moment of failure, the device has native carrier options already available for activation.

Ask:

• Will profiles be loaded at manufacturing, activation, or later in the lifecycle?
• Does the device need over-the-air profile switching in the field?
• Are backup profiles pre-loaded locally on the SIM, or does switching require a live server connection?
• Who manages profile orchestration across the fleet?

For OEMs preparing for eSIM, profile provisioning affects manufacturing, fulfillment, support, field service, customer experience, and carrier strategy.

4. Do you need multi-carrier eSIM support?

Multi-carrier eSIM support is a resilience strategy for eSIMs. Many devices operate in dynamic, ever-changing environments. A carrier that performs well in one location not be viable across the full geographic reach. Multi-carrier eSIM strategies help OEMs respond to that reality by supporting different carrier profiles for different regions, customer sites, deployment conditions, or coverage requirements.

Multi-carrier support also requires a clear distinction between native carrier profiles and roaming profiles. A native carrier profile connects the device as a direct subscriber on that carrier’s network. This can provide stronger network access, better alignment with carrier features, and more predictable performance for long-term deployments. Native access may also be important for low-power IoT features such as PSM and eDRX, which are often more constrained or inconsistent under roaming models.

A roaming profile connects through a partner network as a guest. Roaming can be useful for broad coverage, early deployment, or mobile use cases, but it may come with lower priority, feature limitations, or permanent roaming restrictions in certain markets.

Ask:

• Will devices operate across regions with different network strengths?
• Do deployments need a fallback option if one carrier underperforms?
• Are you using native carrier profiles, roaming profiles, or a hybrid model?
• Can you manage multiple carriers without juggling multiple portals, contracts, invoices, and support processes?

The goal is to create a managed connectivity strategy that aligns coverage, cost, compliance, and reliability.

5. Are you trying to manufacture a single global SKU?

eUICC can help separate the manufacturing decision from the final connectivity decision. A device can be built once, then localized later with the right carrier profile for the deployment region or customer requirement.

Without eUICC, OEMs often have to make early carrier and region decisions. Devices may need different SIMs, different carrier configurations, or different SKUs based on where they will eventually be deployed. That adds complexity to procurement, forecasting, inventory, fulfillment, and support.

That is especially valuable when the OEM does not know the final destination at the time of production. Devices may sit in inventory, ship through distribution partners, or serve customers in multiple markets. A single hardware configuration with flexible connectivity can reduce operational friction across the entire supply chain.

Ask:

• Can one hardware configuration support multiple regions?
• Can connectivity be localized after manufacturing without physical SIM access?
• Can the device ship before the final carrier decision is made?
• Can the same SKU serve North America, Europe, and other global markets?

eSIM can make single-SKU deployment more practical when the broader architecture supports it.

6. Have you considered permanent roaming and data sovereignty?

Permanent roaming is not always a long-term strategy. If a device remains in one country for months or years, the deployment may trigger permanent roaming restrictions, carrier enforcement policies, or data sovereignty concerns.

Brazil is one commonly cited example. Industry guidance notes that non-Brazilian profile roaming may not extend beyond 90 days under Brazilian restrictions. Turkey is another key example, with sources describing a rule that allows roaming for only 90 days within a 120-day period on Turkish networks.

The European Union has its own fair-use framework for roaming. Under EU consumer roaming rules, operators can monitor usage over a four-month period and may apply additional charges if usage and presence are predominantly abroad rather than domestic. While IoT and M2M deployments may be treated differently depending on contract and market, the broader point remains: long-term connectivity strategy cannot assume that roaming is always acceptable forever.

Data sovereignty adds another layer. Some customers, especially in enterprise, banking, healthcare, government, and regulated industries, may require data traffic to remain within a specific country or region. Others may want to know who has access to the data path and whether traffic is routed through a provider architecture that introduces unnecessary security or compliance exposure.

Ask:

• Will devices remain in one country long enough to trigger permanent roaming restrictions?
• Are there local regulations that make roaming-only connectivity unsuitable?
• Do customers require data traffic to remain in-country?
• Do enterprise, banking, healthcare, or government customers have stricter data-routing expectations?

For long-term stationary deployments, eSIM readiness often means planning for native carrier profiles, localized connectivity, local breakout, or a hybrid strategy that keeps devices compliant and connected over time.

7. Can your business manage connectivity after launch?

Connectivity requires ongoing management. Data plans may need to change. Usage may spike. Customers behavior patterns will evolve with the devices. A deployment may expand into a new market. A device may need to move from one profile to another.

If those workflows require spreadsheets, disconnected carrier portals, manual billing reconciliation, and support tickets across multiple vendors, the operational value of eSIM can disappear quickly.

Ask:

• Who activates, suspends, transfers, or retires devices?
• Can support teams see device status, usage, carrier, and billing details in one place?
• Can the business manage data plans, usage alerts, and subscription billing?
• What happens when a customer stops paying but the SIM remains active?

That last question is especially important for OEMs that resell connectivity or bundle it into a recurring subscription. If a SIM stays active after the end customer stops paying, the OEM continues absorbing cellular costs. Over hundreds or thousands of devices, that can become a margin problem.

A mature eSIM strategy should connect the technical lifecycle with the commercial lifecycle. Activation, billing, payment status, suspension, and support should not live in separate systems that require manual reconciliation.

8. Do you have the right IoT connectivity partner?

A SIM reseller can provide connectivity access. A true IoT connectivity partner helps you make the right decisions across hardware, certification, carrier strategy, provisioning, profile management, compliance, operations, billing, and long-term lifecycle management.

Ask:

• Does the provider understand IoT device roadmaps, not just SIM procurement?
• Do they have direct MNO relationships, or are they reselling roaming access from another MVNO?
• Can they advise on certification, profile strategy, native vs. roaming connectivity, and global rollout planning?
• Do they provide connectivity management and billing tools?
• Can they support connectivity monetization for OEMs that want to resell connectivity as a recurring revenue stream?

eSIM functionality gives OEMs more flexibility, but that flexibility has to be orchestrated. Without the right partner, an eSIM deployment can still become fragmented across carriers, contracts, portals, invoices, profiles, and support paths.

How Zipit helps IoT OEMs prepare for eSIM deployments

For OEMs preparing to launch or scale connected devices, Zipit provides carrier-agnostic guidance around the connectivity model that best fits the device, market, use case, and business roadmap. That may involve native carrier profiles, roaming connectivity, multi-carrier strategies, regional connectivity planning, or a balanced hybrid model.

Zipit also helps OEMs navigate global carrier access. With global Tier-1 carrier relationships and hands-on experience supporting IoT device deployments, Zipit can help teams understand carrier certification requirements, network access considerations, profile strategy, and deployment planning before devices are already in the field.

For eSIM and eUICC deployments, Zipit’s approach is designed to solve one of the most important operational problems: profile switching only works if the device has a viable path to switch. By supporting native profiles pre-loaded on the SIM, Zipit can help reduce the risk of relying on a live provisioning connection at the exact moment a device needs failover.

Beyond connectivity access, Zipit gives OEMs a single operational model for managing connected devices. Teams can gain visibility into device status, usage, carrier activity, billing, and lifecycle actions through a single pane of glass instead of stitching together multiple carrier portals and spreadsheets.

Zipit also supports the business side of connectivity. For OEMs that want to bundle connectivity into a subscription, resell data plans, or turn recurring cellular costs into recurring revenue, Zipit provides billing and monetization support that helps connect payment status, plan management, activation, and suspension workflows.

Zipit provides a complete model for IoT connectivity: one partner, one contract, one invoice, one management layer, and one operational strategy across connectivity and recurring revenue. Contact Zipit to talk through your eSIM readiness strategy and build a connectivity model that supports your IoT deployment from first activation through full lifecycle management.

Simplify multi-carrier connectivity with Zipit eSIM Integrated

Zipit eSIM Integrated is an eUICC with four certified, pre-loaded native profiles from AT&T, Verizon, and T-Mobile: two from AT&T and one each from Verizon and T-Mobile. Zipit loaded all four so that a single SIM could support every network type, rate plan, and service the three carriers offer through Zipit, from low-power Cat-M1 sensors on small KB plans to fixed wireless routers on unlimited business internet plans, including VoLTE and SMS. 

Those profiles are managed by an eIM and an IoT Profile Assistant embedded directly in the SIM (IPAe), following the GSMA SGP.32 architecture for IoT. Because the orchestration lives on the SIM and in Zipit’s platform rather than in the device, product teams get zero-touch profile configuration and automatic failover without writing carrier-switching logic into their firmware. The connectivity strategy can change after deployment while the hardware stays the same.

Here’s how it lines up against the checklist:

• Hardware readiness: No carrier-switching logic to build into device firmware. Profile management runs on the SIM and in Zipit’s platform. Available as a TriCut removable SIM (mini, micro, nano) or an embedded MFF2 chip.
• Certification: Devices still need carrier certification, as with any native SIM, but Zipit adds no certification requirements of its own.
• Failover: Backup profiles are already on the SIM, so automatic failover between U.S. carriers doesn’t depend on reaching a provisioning server in the middle of an outage.
• Native multi-carrier access: Zipit is an authorized MVNO of all three major U.S. carriers, so devices connect on-net rather than as roaming guests. That keeps features like eDRX, VoLTE, and SMS available, which are often unavailable or uneconomical over roaming agreements.
• Single SKU: One SIM covers Cat-M1 and NB-IoT through 5G RedCap and 5G, with plans from 250KB up to unlimited and fixed wireless access. The same part number can ship in a battery-powered sensor or a business internet router.
• After launch: Profiles, connectivity policies, and rate plans for all three carriers are managed from one platform, with Tier 1 authorized roaming available for devices deployed outside the U.S.

Talk to Zipit about your eSIM strategy to explore the right approach for your devices.

You may also like

• What Is Multi-Network Connectivity?
• Native Connectivity: The Trend Happening in Markets Around the World
• Permanent Roaming for IoT: Challenges, Risks, and Solutions
• 10 Key Features of an IoT Connectivity Management Platform
• What Is IoT Device Certification and Why It Matters