eSIM Technology – How It Works & Why Integration Matters

Most conversations about eSIM stop at the business case. Remote provisioning, reduced logistics, better fleet flexibility. All of that is accurate & none of it is the hard part. The hard part is what happens after the eUICC is soldered into the device & the business case has been approved. The hard part is making the provisioning architecture work reliably across thousands of devices, across geographies, across operator configurations, across firmware update cycles, over an operational lifetime that may span years.

eSIM is not difficult because of the chip. The eUICC is a mature, well-specified component. What is difficult & what most organisations underestimate until they are already in production, is the protocol & integration layer that turns eSIM capability into a reliable operational system. The eUICC is the starting point. What sits above it - the provisioning infrastructure, the device software stack, the MDM platform, the OTA architecture, the operator relationships, is where eSIM either works or does not.

This article is written for two groups of organisations that must make that stack work in practice: device manufacturers embedding eSIM into hardware & enterprises deploying connected device fleets at scale. The problems look different from each position. The underlying architecture they depend on is the same.

Could Your eSIM Program Have an Integration Gap?

An eSIM implementation can work technically & still carry production risk. A successful profile download does not prove that the provisioning model, profile lifecycle, firmware, LPA/IPA & eUICC behaviour, or field connectivity are aligned. Gaps between these layers may remain hidden until a profile switch, an OTA update or an operator change leaves devices unable to reconnect.

For device manufacturers & enterprises, the practical question is whether complete architecture can keep devices connected & recover failures throughout their operational life. Identifying these integration gaps before deployment helps avoid service disruption, field intervention & costly rework at scale.

What Is eSIM Technology & How Does It Work?

What Is an eUICC? Understanding the Technology Behind eSIM

The physical SIM card is a removable secure element that stores the subscriber credentials an operator needs to authenticate a device on its network: the IMSI, the authentication keys, the network access configuration. When you remove a SIM & insert a new one, you are physically replacing those credentials. The device has no say in what it connects to.

The eUICC - Embedded Universal Integrated Circuit Card – changes that relationship entirely. It is a secure element soldered into the device, with the same tamper-resistant architecture as a physical SIM but with one fundamental difference: the identity it carries is software. Operator profiles – structured data packages containing the IMSI, authentication credentials, network access application & operator-specific configuration are all delivered & managed over the air. A single eUICC can hold multiple profiles simultaneously, switch between them, receive new ones & delete obsolete ones without anyone physically accessing the device.

That shift from a physical credential to a software-managed identity – is not an incremental improvement. It is a rearchitecting of how devices relate to networks. The device no longer has a fixed network identity determined by the card inside it. It has a managed connectivity architecture that can be configured, updated & changed throughout its operational lifetime. That is a fundamentally different kind of system & it requires a fundamentally different kind of engineering to operate reliably.

What Is an eSIM Operator Profile & How Does It Work?

An operator profile is not a digital copy of a SIM card. It is a structured software package – defined by GSMA specification – containing the subscriber identity, the cryptographic authentication credentials, the network access application, the operator file system & any toolkit applets the operator includes. When a profile is installed on an eUICC & enabled, it creates a complete, isolated software representation of a subscriber relationship with that operator.

Enabling a profile connects the device to that operator's network. Disabling it suspends the connection without deleting the credentials. Deleting it removes the profile from the eUICC but does not necessarily cancel the operator subscription. Managing this across a fleet is where the real complexity lives. Profile state is a property of the eUICC – a stateful system with its own lifecycle, independent of the device OS. A profile switch initiated remotely but interrupted by a connectivity loss can leave a device in an indeterminate state. A firmware update that touches the eUICC HAL without accounting for active profile state can produce connectivity failures that are invisible until the next attempts a network operation. The eUICC is not simply a component. Its state must be managed with the same rigour as any other stateful system in the device architecture.

eSIM Architecture: Understanding the Protocol Layer

SGP.22 vs SGP.32: What Is the Difference?

Within the GSMA remote SIM provisioning framework, SGP.22 & SGP.32 are the two architectures particularly relevant to the deployments discussed here. Choosing between them is one of the most consequential decisions a device manufacturer makes during hardware design – because it shapes the provisioning model, the server infrastructure, the device software requirements & the operator integration approach for the device's operational life. The right choice follows the deployment model, not simply what is more widely available or familiar.

SGP.22, the Consumer RSP specification was designed around a specific assumption: that a user is present to drive the provisioning flow. A smartphone user scans a QR code, the device's Local Profile Assistant connects to the operator's provisioning server & the profile is downloaded & installed under user direction. The architecture is pull-based & user-initiated. It works well for devices where user interaction at the point of provisioning is a reasonable expectation.

SGP.32 v1.3 (dated 22 May 2026) is designed for network-constrained and/or user-interface-constrained IoT devices, often operating without a user or screen. Industrial sensors, ruggedised handhelds, vehicle telematics units, medical monitoring devices & edge AI nodes cannot depend on user initiation. SGP.32 adds an eSIM IoT Remote Manager (eIM) for remote orchestration & an IoT Profile Assistant (IPA), located in the device (IPAd) or eUICC (IPAe), to carry out profile operations. A usable communication path is still required when provisioning occurs.

The architectural implication is direct: a device manufacturer who selects SGP.22 for industrial deployment because it is more widely supported is building a user-driven provisioning model into a device that will have no users at the point of deployment. The provisioning flow will require workarounds. The fleet management architecture will not fit the specification. The consequences tend to surface not in controlled testing, but when the first large-scale deployment encounters field conditions the specification was not designed for. Specification choice should follow the deployment model. That is a more important decision than any component selection in the eSIM stack.

SM-DP+, SM-DS & eIM: How eSIM Provisioning Works

The SM-DP+ – Subscription Manager Data Preparation Plus – is the server-side component that creates, protects & delivers operator profiles to eUICC-enabled devices. When an operator provisions a device, the subscriber data is packaged into a bound profile package: encrypted & cryptographically signed specifically for the target eUICC, so that only that device's secure element can install it. This binding is what makes profile interception operationally useless – the package cannot be installed on any other device.

In the consumer SGP.22 architecture, the SM-DS – Subscription Manager Discovery Server – acts as a notification relay. When an SM-DP+ has a profile ready, it registers a pending notification. When the device checks in, it learns which SM-DP+ to contact & initiates the download. In SGP.32, the eIM orchestrates profile downloads & lifecycle operations through the IPA & SM-DP+; SM-DS remains an optional discovery mechanism & is not replaced by the eIM.

For enterprise architects, the practical question is not which of these servers to use – the specification determines that. The question is what integration work connects these provisioning components to the existing device management infrastructure. SM-DP+ is not a service that plugs in automatically. It requires integration with the operator's systems, alignment with the MDM platform's profile management API & testing across the full range of hardware & connectivity conditions the fleet will encounter. Treating the provisioning server as a third-party concern is where many enterprise eSIM programmes begin to run into difficulty.

What Is LPA in eSIM & Why Is It Important?

In the consumer SGP.22 architecture, the LPA – Local Profile Assistant – is the software component on the device that manages all communication between the eUICC & the external provisioning infrastructure. It connects to the SM-DP+, executes the mutual authentication sequence, downloads & installs the bound profile package & manages profile lifecycle operations on behalf of the user or MDM platform. It is the integration point between the secure hardware of the eUICC & every system that needs to interact with it. In SGP.32 IoT RSP, the IPA performs the device-side role under eIM coordination.

On a stock Android device from a major OEM, the LPA is provided as part of the system software. On a custom AOSP platform – which covers a significant portion of enterprise & industrial device deployments – there is no OEM-provided LPA. It must be implemented as part of the custom firmware. This is one of the most consistently underestimated pieces of work in enterprise eSIM programmes. The LPA implements a defined interface, communicates with the eUICC through the HAL layer, handles certificate-based mutual authentication with the SM-DP+, manages error states & retries across unreliable connectivity & integrates with the MDM platform for remote profile lifecycle operations.

A custom AOSP device without a correctly implemented LPA is an eSIM-capable device that cannot be operationally provisioned. The eUICC is correct. The hardware is right. The integration is absent & because the LPA sits between the hardware & everything above it, an incomplete LPA implementation does not fail in one predictable way. It fails differently depending on the operation attempted, the operator configuration in use & the connectivity environment the device is operating in. It is the kind of failure that can pass a controlled lab test & surface at production scale.

eSIM Security Architecture: Certificates & Mutual Authentication

The security model of eSIM provisioning is built on a chain of trust rooted in the GSMA’s Certificate Issuer infrastructure. Every eUICC carries a device-specific certificate signed by its manufacturer, whose own certificate chains up to a GSMA-recognised root. Every SM-DP+ carries a corresponding certificate. When a device initiates a profile download, the eUICC & SM-DP+ perform mutual authentication through the LPA: each verifies the other’s certificate chain against the GSMA root, & the eUICC generates a one-time session challenge that the SM-DP+ must sign correctly before any profile data is transferred. The profile package is encrypted specifically for the target eUICC & can only be decrypted by that chip.

This is a sound security architecture, but it is only as strong as its implementation at each step. A device whose eUICC certificate chain was not correctly provisioned during manufacture may fail authentication without producing a clear error. It will be unable to receive profiles, & the gap stays undiscovered until the first provisioning attempt in the field. An MDM platform that initiates profile operations without maintaining visibility into eUICC certificate state across its fleet will generate provisioning failures that are difficult to diagnose remotely. The security model of eSIM works as designed. The failure modes live at the boundary between specification & implementation, which is precisely where integration engineering operates.

Why eSIM Deployments Fail at Scale?

eSIM Integration Challenges for Device Manufacturers

The decisions that most shape the success of an eSIM device program are made before the first line of firmware is written. eUICC form factor – whether solderable MFF2, an iSIM integrated into the SoC, or a discrete chip – determines the thermal, power & space trade-offs for the production run of the device. Specification choice determines the provisioning architecture every downstream system must be built to support. LPA strategy – whether to use the eUICC vendor's reference implementation, adapt it, or build from specification – determines where validation risk sits & how much firmware engineering work remains.

The most common failure pattern is treating the eUICC as a component selection & the LPA as a firmware detail to address later. By the time firmware development begins, the hardware is fixed. If the chosen eUICC requires HAL implementation the AOSP BSP does not yet support, the firmware team inherits a porting problem that was avoidable. If the specification does not match the deployment model – a consumer SGP.22 implementation on a device with no user interface & no reliable connectivity at provisioning time – the architecture may need to be reconsidered after the hardware has already been manufactured. The integration decisions that feel like details during hardware design tend to be the ones that determine production outcomes. They must be treated as architecture decisions from the start.

Enterprise eSIM Integration: Managing Connected Device Fleets

An enterprise deploying a fleet of eSIM-capable devices faces a structurally different problem. The device has been selected, the eUICC is correctly provisioned & the LPA is implemented. The pilot worked. The assumption is that production will follow. It will not – not automatically, not at fleet scale & not reliably unless the systems built around the device were designed for operational scale from the beginning.

An MDM platform that manages applications & OS updates across the fleet but has no native capability to manage eSIM profile lifecycle – enable, disable, switch, delete – creates a parallel connectivity toolchain that operates independently of every other device management operation. A firmware update that inadvertently modifies the LPA implementation or the eUICC HAL can silently affect remote provisioning for devices in the fleet that receive it – with no failure visible until the next profile operation is attempted. A profile switch initiated during a connectivity window that closes before the operation completes can leave a device stranded between profiles, unable to connect on either operator, in a field environment where dispatching a technician is not a viable response.

Each of these failure modes is manageable in a ten-device pilot. At ten thousand devices – across multiple hardware production batches, varying eUICC firmware revisions & geographies with different operator configurations – the boundaries between eUICC, HAL, LPA, provisioning infrastructure, MDM & OTA become the points where the integration either holds or fractures. Scale does not create new problems. It reveals the integration gaps that were always present but small enough to absorb in a controlled environment.

How UnfoldLabs Enables Production-Ready eSIM Integration?

eSIM integration is a connected architecture problem. The eUICC, the HAL, the LPA, the provisioning infrastructure, the MDM platform & the OTA system must be designed as a coherent whole – not as independent components integrated in sequence. A decision made at the eUICC selection stage affects what is possible at the LPA layer. A gap in MDM integration creates an operational problem that surfaces at fleet scale. The quality of certificate provisioning at manufacture determines whether remote profile management works in the field. These are not parallel concerns. They are sequential dependencies & a failure at any layer propagates to every layer above it.

UnfoldLabs works at the hardware-software integration layer of custom AOSP platforms, where these dependencies are resolved before the device ships. For device manufacturers, that means eUICC selection & specification alignment matched to the actual deployment model, HAL & LPA implementation on custom AOSP firmware & certificate validation & authentication testing against the provisioning infrastructure. For enterprise fleet programs, it means MDM integration for profile lifecycle management, OTA design that accounts for eUICC & LPA state & fleet-scale validation across hardware variants, operator configurations & connectivity environments. The objective in both cases is the same: not to prove that eSIM works in a lab, but to ensure it keeps working in production.

Our engagement starts with the deployment model: who initiates provisioning, where devices operate & how connectivity must be maintained over their lifetime. We then validate eUICC & device-stack compatibility, LPA/IPA integration & MDM/OTA workflows. Failure recovery is tested across operator configurations, firmware versions & connectivity conditions, including interrupted profile operations, so production readiness is assessed across the complete system.

The organisations that get eSIM right – both the manufacturers building it in & the enterprises operating it at scale – treated the integration as an architecture problem & addressed it before the first device shipped. That discipline is what this work requires. It is what UnfoldLabs brings to every eSIM program.

My Thoughts

The real shift that eSIM represents is not from a physical SIM card to an embedded chip. That is the visible change & it is the one that receives the most attention. The more significant shift is from connectivity as a fixed component to connectivity as an engineered system. A physical SIM defines a device's network relationship at manufacture & holds it there. An eSIM makes that relationship dynamic – configurable, updatable & manageable across the operational lifetime of the device. That is fundamentally more capable architecture. It is also a fundamentally more demanding one.

A dynamic system requires more engineering than a fixed one. Every layer that becomes configurable is also a potential point of failure if it is not managed correctly. The provisioning infrastructure must handle configuration reliably at scale. The device software must maintain correct state across firmware updates, connectivity interruptions & profile lifecycle events. The MDM platform must treat eUICC state as a first-class operational signal – not an afterthought. None of this complexity is unique to eSIM. It is the standard engineering challenge of any system where flexibility is a design goal. What is particular to eSIM is that this complexity tends to be invisible until production scale, at which point it becomes the most expensive problem in the programme.

Connectivity is no longer a component. It is architecture. & architecture must be designed – deliberately, end to end, before the first device ships. The organisations that understand this will build eSIM programmes that scale. The ones that treat the chip as the solution will build programmes that work in the pilot & struggle in production.

eSIM does not make connectivity simpler. It makes connectivity programmable. Whether that becomes an operational advantage or a recurring integration problem depends entirely on the engineering discipline you bring to everything built around the chip.

Asokan Ashok
CEO, UnfoldLabs Inc.

Is Your eSIM Architecture Ready for Production Scale?

Before production scale exposes integration gaps, talk to UnfoldLabs about your eSIM architecture. Whether you are building a custom device or expanding a connected fleet, we can help assess the provisioning model, device-stack dependencies & recovery workflows that determine reliable operation in the field. Start the conversation while those decisions can still be addressed in the design.