eSIM & eUICC Architecture: The Complete Technical Guide

Published July 28, 2026 · ~10,000 words · Smart Card & Embedded SIM Engineering

1. What Is an eSIM? The eUICC Distinction

The term eSIM (embedded SIM) is often used loosely to refer to two distinct things: the physical eUICC chip soldered onto a device PCB, and the consumer-facing "eSIM" feature that lets users download carrier profiles over-the-air. Understanding the distinction is fundamental.

An eUICC (Embedded Universal Integrated Circuit Card) is a tamper-resistant secure element — a smart card chip permanently soldered to a device's motherboard. It runs a GlobalPlatform-compliant card operating system that supports remote profile provisioning. The eUICC can store multiple MNO profiles (operator subscriptions), each isolated in its own security domain. Unlike a traditional removable SIM card (UICC), the eUICC is not physically swappable — instead, profiles are downloaded, enabled, and deleted over-the-air through a standardized protocol called Remote SIM Provisioning (RSP).

Key specifications governing eUICC:

• GSMA SGP.22 — RSP Technical Specification for Consumer Devices (smartphones, tablets, wearables)
• GSMA SGP.02 — RSP Technical Specification for M2M Devices (IoT, automotive, industrial)
• ETSI TS 103 383 — eUICC Profile Package: Interoperable Format
• GlobalPlatform Card Specification — Underlying card OS and security domain model
• ISO 7816-4 — APDU transport (the physical/logical channel to the eUICC)
• 3GPP TS 31.101 / 31.102 — UICC/USIM file system and commands

2. GSMA SGP.22 — The Consumer eSIM Standard

GSMA SGP.22 defines the end-to-end architecture for consumer eSIM provisioning. This is the standard that powers eSIM on Apple iPhone (XS and later), Google Pixel, Samsung Galaxy, and most consumer eSIM-capable devices.

Architecture Components

+------------------+       +------------------+       +------------------+
|   LPA (Device)  |       |   SM-DP+         |       |   MNO Backend    |
|  (LPAd + LPAe)  |<---->| (Profile Server)  |<---->|  (BSS/OSS)       |
+------------------+       +------------------+       +------------------+
        |                          |
        | ES10a/b/c               | ES2+
        v                          v
+------------------+       +------------------+
|   eUICC Chip     |       |   SM-DS          |
|  (ISD-R + ISD-Ps)|       | (Discovery Srv)  |
+------------------+       +------------------+

SGP.22 Interfaces

3. LPA (Local Profile Assistant) Deep Dive

The LPA (Local Profile Assistant) is the client-side software component that mediates between the user/OS and the eUICC. In the SGP.22 architecture, it is split into two functional modules:

LPAd (LPA in Device)

The LPAd runs on the device's application processor (Android/Linux/iOS userspace). It provides the user-facing UI for profile management — scanning QR codes for activation, showing installed profiles, letting users switch between carriers. The LPAd talks to the eUICC through APDU commands over the device's ISO 7816 physical interface.

LPAe (LPA eSIM) — Formerly "LPA in eUICC"

The LPAe runs within a dedicated applet on the eUICC itself. Despite its misleading name (it was renamed from "LPA in eUICC"), it handles the HTTPS-based communication with SM-DP+ and SM-DS servers. The LPAe establishes TLS sessions, authenticates with profile servers, and orchestrates the ES11 mutual authentication handshake. The split design keeps the cryptographic heavy-lifting and network I/O separate from the constrained eUICC execution environment.

LPA ↔ eUICC Communication: modem AT Commands

On devices with an integrated modem, the LPAd typically routes APDUs to the eUICC through the modem's AT command interface (3GPP TS 27.007). The key AT commands are:

• AT+CSIM — Generic UICC APDU transport (used for all eUICC commands)
• AT+CCHO — Open logical channel
• AT+CCHC — Close logical channel

LPAe ↔ SM-DP+ Protocol: ES11

The ES11 interface is a four-step mutual authentication protocol:

1. InitiateAuthentication — LPAe sends eUICC challenge and EID to SM-DP+
2. SM-DP+ responds with server challenge, signed profile metadata, and DP+ certificate chain
3. LPAe verifies SM-DP+ certificate (PKI chain validation up to GSMA CI root)
4. LPAe sends GetBoundProfilePackage with eUICC-signed confirmation
5. SM-DP+ delivers the Bound Profile Package (BPP — the encrypted eSIM profile)

4. ISD-R and ISD-P Security Domains

The eUICC's GlobalPlatform card OS uses a hierarchy of security domains to isolate profiles and manage the provisioning state machine:

ISD-R (Issuer Security Domain — Root)

The ISD-R is the root security domain of the eUICC. It has Card Manager privileges and controls the lifecycle of all other security domains. The ISD-R:

• Manages ISD-P creation and deletion — one ISD-P per installed profile
• Controls profile download, enable, disable, and delete operations
• Maintains the Profile Policy Enabler (PPE) rules
• Enforces the eUICC state machine (CREATED → ENABLED → DISABLED → DELETED)
• Is provisioned at manufacturing time with the EUM (eUICC Manufacturer) certificate

ISD-P (Issuer Security Domain — Profile)

Each installed MNO profile gets its own ISD-P. The ISD-P is the container that holds:

• The profile's USIM/ISIM application code and filesystem
• MNO-SD keys (used for OTA updates after installation)
• Profile metadata: ICCID, profile name, MNO ID, profile class

eUICC State Machine

  [Empty] --Download--> [Disabled] --Enable--> [Enabled]
                              ^                    |
                              |____Disable_________|
                              |
                          [Deleted] (GC reclaims memory)

5. SM-DP+ and SM-DS — Profile Delivery Servers

SM-DP+ (Subscription Manager — Data Preparation+)

The SM-DP+ is the server that securely generates, encrypts, and delivers eSIM profiles. It is operated by the MNO or a third-party eSIM platform vendor (e.g., Idemia, G+D, Thales, Truphone, Kigen). The SM-DP+:

• Receives profile orders from MNOs via ES2+ (typically REST API)
• Generates the Bound Profile Package (BPP) — a one-time-use encrypted profile tied to a specific EID
• Authenticates the target eUICC through the ES11 mutual auth handshake
• Stores the GSMA CI (Certificate Issuer) root certificate chain for verifying GSMA PKI signatures
• Maintains an Event Registration queue for pending profile notifications

SM-DS (Subscription Manager — Discovery Server)

The SM-DS is an optional intermediary that acts as a "push notification" service for eSIM profiles. Instead of requiring the user to scan a QR code with the SM-DP+ address directly, the SM-DP+ registers a pending profile event with the SM-DS. The LPAe periodically polls the SM-DS. When a matching event is found (by EID or notification ID), the LPAe retrieves the SM-DP+ address and initiates the profile download. This is the mechanism behind "carrier activation" where a profile appears automatically.

6. eSIM Profile Structure and Download Flow

Profile Package Format

An eSIM profile package (Profile Package — PP) is a TLV-encoded blob containing:

• Profile Header — ICCID, MNO-ID, profile version, profile type
• PE-TLV (Profile Element TLV) — The actual file system: MF, DF, EF structures
• NAA TLV — Network Access Application credentials (USIM keys, authentication algorithms)
• Security Domain TLV — ISD-P keys and lifecycle state
• Profile Metadata — Human-readable name, icon, service provider name

Full Profile Download Sequence

LPAe                                SM-DP+                    eUICC (ISD-R)
 |                                    |                         |
 |-- ES11 InitiateAuthentication ---->|                         |
 |   (eUICCChallenge, EID, Info1)     |                         |
 |                                    |                         |
 |<-- Server response ---------------|                         |
 |   (TransactionId, DpSigned,        |                         |
 |    DpCertificateChain, ServerChlg) |                         |
 |                                    |                         |
 |-- Verify DP+ cert chain --------->|                         |
 |   (against GSMA CI root)           |                         |
 |                                    |                         |
 |                                    |     ES10b PrepareDownload(BPP)
 |<-- ES11 GetBoundProfilePackage --->|<-----> eUICC decrypts, installs
 |   (eUICC-signed confirmation)       |       ISD-P, profile content
 |                                    |
 |<-- Profile installed, ISD-P created
 |
 |-- ES10b EnableProfile(ICCID) ----> eUICC switches to new profile
 |-- Modem refresh (REFRESH proactive command)

BPP (Bound Profile Package)

The BPP is the key security mechanism. It is a profile encrypted specifically for one eUICC. The SM-DP+ generates a session key using ECDH key agreement with the eUICC's ephemeral public key (from the eUICC challenge). The BPP cannot be installed on any other eUICC, even if the encrypted blob is intercepted. This is the "bound" in Bound Profile Package — it is cryptographically bound to one specific EID.

7. M2M eUICC (SGP.02) vs Consumer eUICC (SGP.22)

8. eUICC APDU Commands Reference

All eUICC management commands use APDUs addressed to the ISD-R AID (A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 01 00). Below is a summary of the key ES10a/b/c commands:

ES10a — eUICC Information

ES10b — Profile Management

ES10c — Platform Management

Example: Get EID — APDU Exchange

>> 00 A4 04 00 0F A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 01 00   [SELECT ISD-R]
<< 90 00

>> 80 CB 00 00 00                                                [GET EID, Le=00 (max)]
<< 1E 38 39 30 34 39 30 33 32 30 30 30 30 30 30 30   [EID: 890490320000000...]
    30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
    90 00

9. eUICC Chip Internals and Hardware

The eUICC chip is a secure microcontroller built on smart card silicon. Leading eUICC chip vendors include Infineon (SLC37 series), STMicroelectronics (ST33G), NXP (SN110), Samsung (S3K250AF), and Thales/G+D/Idemia for the OS layer.

Hardware Architecture

• CPU: ARM SecurCore SC300 or proprietary 8/32-bit secure MCU, typically 25-50 MHz
• ROM: 256-512 KB for bootloader and crypto libraries (mask ROM, immutable)
• EEPROM / Flash: 512 KB — 1.5 MB for OS + profiles (each profile ~64-200 KB)
• RAM: 8-32 KB (volatile, cleared on power loss)
• Crypto Co-processor: Hardware AES, DES/3DES, RSA, ECC (P-256), SHA-256
• TRNG: True Random Number Generator (FIPS 140-2 compliant)
• Physical Interface: ISO 7816-3 (T=0 protocol, 5 contact pins typically: VCC, GND, RST, CLK, I/O)
• Optional Interfaces: SPI (for M2M eUICC), I2C (for soldered eUICC in IoT SoCs)

EID (eUICC Identifier)

The EID is a globally unique 32-digit identifier for each eUICC chip. Format:

EID = EUM_Code (5 digits) + ICCID_Prefix (4 digits) + IndividualNumber (21 digits) + CheckDigit (2 digits)

The EID is laser-engraved into the eUICC silicon or stored in one-time programmable (OTP) memory. It is analogous to the ICCID of a physical SIM but permanently bound to the chip. The EID is what the user provides to the MNO for profile ordering — the carrier uses it to tell the SM-DP+ "generate a profile for this specific chip."

10. Android & iOS LPA Implementation

Android EuiccManager API

Since Android 9 (API 28), Android provides the EuiccManager system service as part of the telephony framework. Key API operations:

// Get EuiccManager instance
EuiccManager em = context.getSystemService(EuiccManager.class);

// Check if device supports eSIM
boolean enabled = em.isEnabled();

// Start resolution activity (QR scan or carrier activation)
Intent intent = new Intent(EuiccManager.ACTION_START_RESOLUTION_ACTIVITY);
// ...

// Switch to a profile
em.switchToSubscription(subscriptionId, callback);

// Delete a profile
em.deleteSubscription(subscriptionId, callback);

The Android LPA implementation delegates ES10x APDUs to the modem through the Radio Interface Layer (RIL). The EuiccService (part of the proprietary LPA implementation by the device OEM or Google) translates Android API calls into APDUs sent to the eUICC.

iOS Core Telephony + eSIM

Apple's eSIM implementation is closed-source, but the public APIs include:

• CTCellularPlanProvisioning — Request eSIM from carrier (iOS 12+)
• CTCellularPlanProvisioningRequest — Configure activation request details
• QR code scanning: iOS Camera app natively recognizes GSMA activation codes

GSMA Activation Code Format

The QR code that users scan to activate an eSIM contains a GSMA-defined activation code:

LPA:1$smdp.example.com$MNO-ACTIVATION-CODE-12345

Or for SM-DS activation:

LPA:1$SMDS$mno-activation-code-67890

Summary

The eSIM ecosystem is a complex stack spanning hardware (eUICC chip), firmware (GlobalPlatform card OS + ISD-R/ISD-P), client software (LPA), network servers (SM-DP+/SM-DS), and carrier backends (MNO BSS). Understanding each layer — from the APDU on the wire to the GSMA PKI certificate chain — is essential for anyone working on embedded SIM development, eSIM testing, or eUICC platform integration.

Key takeaways:

• eUICC ≠ eSIM — the former is the chip, the latter is the user-facing feature
• GSMA SGP.22 defines the consumer architecture; SGP.02 is for M2M
• The LPAe on the eUICC performs HTTPS/TLS to SM-DP+ — the eUICC has a network stack
• Every profile is cryptographically bound to one EID through the BPP mechanism
• eUICC APDU commands follow standard GlobalPlatform framing with a custom eUICC AID