Why an embedded subscriber identity module (eSIM) is not one thing

“The embedded subscriber identity module (eSIM) is not working” sounds like one problem. It can actually describe failures in three very different systems: a carrier profile, the secure component that stores it, or the remote service that delivers it.

That ambiguity is built into the language. In everyday use, eSIM can mean a travel plan, a Quick Response (QR) code, an installed mobile line, or the hardware inside a phone. Those are related, but they are not interchangeable.

This post is a technical map of the system underneath the label. We will use it to answer a practical question: when a digital mobile line is installed, what is actually happening?

Subscriber identity module (SIM) is the established industry term for the secure subscriber-identity application traditionally associated with a removable SIM card. The same term remains in use even when the secure component is embedded in a device.

The architecture in one diagram

An eSIM system has three layers: a profile; an embedded universal integrated circuit card (eUICC), the secure component in the device; and Remote SIM Provisioning (RSP), the control plane that delivers and manages the profile.

The profile is the subscription that can authenticate to a mobile network. The eUICC stores and manages profiles. RSP is the standards-based mechanism that gets a profile onto the eUICC and manages it afterwards.

The eSIM experience is the combination of all three.

The abstraction leak

Physical subscriber identity module (SIM) cards made the model easy to see. A carrier gave you a card; you placed it in a phone; the card held the subscription.

With eSIM, the subscription can move without a new card. That is the point. But it also means that “the SIM” is no longer a useful description of a single object.

Layer	What it does	What can change
Profile	Contains the subscription data used to join a network	It can be installed, enabled, disabled, or deleted
eUICC	Stores and protects profiles	It remains in the device
RSP	Delivers and manages profiles remotely	Its flow and policy vary by provider and device

The eUICC has its own permanent identifier, the embedded universal integrated circuit card identifier (EID). A profile has its own identifiers, including an integrated circuit card identifier (ICCID). Deleting a travel profile removes a subscription from the eUICC; it does not remove the phone’s eSIM capability.

That distinction explains a common support question: a phone can still support eSIM after an installed eSIM has been deleted, because the durable component and the removable profile are different layers.

How a consumer eSIM is installed

Consumer remote SIM provisioning is defined by the Global System for Mobile Communications Association (GSMA) consumer architecture, commonly called the SGP.22 technical specification. It is designed for the familiar case: a person chooses a plan and installs it on a phone, tablet, or watch.

At a high level, the flow is straightforward:

1. A provider prepares a profile for an eligible device.
2. The user receives activation information—often a QR code or an in-app install flow.
3. The device’s Local Profile Assistant (LPA) reads that information.
4. The LPA coordinates a secure exchange between the eUICC and the profile-delivery system.
5. The eUICC verifies and installs the encrypted profile.
6. The user enables the line when it is time to use it.

The QR code is therefore not “the eSIM.” It is a bootstrap mechanism. It gives the device enough information to request the intended profile through the provisioning system.

The eUICC is the security boundary in this design. Sensitive network credentials are installed for that secure component rather than exposed as a reusable file for the rest of the phone to handle.

A QR code starts a workflow, not a file transfer

It is natural to imagine a QR code as a portable SIM file: scan it once here, scan it again somewhere else. That model is too simple.

The activation code, provider policy, profile state, and receiving eUICC all affect what happens next. That is why two plans with nearly identical QR-code flows can behave differently:

• one activation code may be single-use while another can be retried
• one profile may be eligible for reinstallation while another is not
• one plan may begin validity on installation while another begins on first network use
• one provider may allow profile transfer while another requires a fresh activation

The standards make the secure delivery mechanism interoperable. They do not make every provider’s commercial policy identical.

The consumer model does not scale to the Internet of Things

The consumer flow assumes a person has a screen, can scan a code, and can decide when to enable a line. That is a reasonable assumption for a phone. It breaks down for a fleet of meters, vehicles, sensors, or industrial devices.

This is what the GSMA’s Internet of Things (IoT) eSIM architecture, the SGP.32 technical specification, is for. It uses a different operating model:

• an eIM (eSIM IoT Manager) coordinates remote profile-management actions
• an IPA (IoT Profile Assistant) receives and executes those actions on or near the device
• the eUICC remains the secure component that holds the profiles

The key difference is control. Consumer RSP puts a user and their device user interface (UI) at the center of installation. IoT RSP puts fleet management and unattended operation at the center.

It would be easy to call SGP.32 “consumer eSIM with fewer QR codes.” That misses the architectural change. SGP.32 is designed so that an organization can manage connectivity across large numbers of devices that may never be physically touched after deployment.

Where iSIM fits

Integrated SIM (iSIM) describes an integration approach rather than a new kind of subscription. It places SIM functionality more tightly inside a device’s system-on-chip instead of using a separate embedded component.

For an end user, an iSIM-enabled device may still look and behave like any other eSIM-capable phone. For a device maker or IoT operator, the difference can matter for space, power, manufacturing, and lifecycle management.

The useful way to remember the terms is:

profile = the subscription
eUICC = the secure profile manager
RSP = the remote control plane
iSIM = a hardware integration model

Debugging the system by layer

Once the layers are explicit, many eSIM problems become easier to classify.

What happened	First layer to investigate
The QR code or install flow is rejected	RSP flow, activation state, or device compatibility
The profile installs but cannot be enabled	Device settings, carrier lock, or profile state
The profile is enabled but data does not work	Data-line selection, roaming, access point name (APN), coverage, or plan state
A deleted profile cannot be added again	Provider reinstallation policy, not eUICC hardware

This does not eliminate provider-specific troubleshooting. It does prevent one unhelpful diagnosis: assuming every failed connection means that “the eSIM chip” is broken.

Why this matters for travel

Travel is where the abstraction becomes visible. A traveler may install a profile at home, leave it inactive until arrival, then connect through a partner network in another country. Each part of that journey belongs to a different layer.

The eUICC stays in the phone. The profile determines which subscription is available. The provisioning flow determines whether it can be installed. Once it is active, normal mobile-network questions still apply: is it the selected data line, is roaming enabled where required, and is there compatible coverage?

That distinction is useful when comparing travel eSIM options: you are choosing a profile and its coverage terms, not a new piece of hardware for your phone.

That is the practical payoff of the model. eSIM is not magic, and it is not a single component. It is a secure system for making mobile subscriptions portable.

Read the standards, not just the marketing

The primary specifications are maintained by the GSMA:

• Consumer eSIM architecture and technical specifications (SGP.21 and SGP.22)
• eSIM Internet of Things architecture and technical specifications (SGP.31 and SGP.32)
• Embedded universal integrated circuit card identifier definition and assignment process (SGP.29)

Further reading from device makers and standards bodies:

• Apple Support: using eSIM while travelling internationally with an iPhone
• Google Pixel Help: learning about eSIMs
• Trusted Connectivity Alliance: Introduction to eSIM
• European Telecommunications Standards Institute: embedded universal integrated circuit card requirements

The specifications evolve. For implementation or compatibility decisions, always use the current GSMA documents and the device or provider documentation that applies to the exact flow you are working with.