eSIM and iSIM Architecture: Embedded SIM Technology for Mobile Devices

The removable SIM has survived for 30 years because it is simple: a tamper-resistant microcontroller on a plastic card that holds the IMSI, Ki key, and carrier applets. But that plastic tray costs board space, adds a failure point, and cannot scale to billions of headless IoT sensors. The industry answer is to embed the SIM — first as a soldered eUICC (eSIM) and now as a logic block inside the cellular SoC itself (iSIM).

Understanding the difference is critical for device architects. An eSIM is still a discrete secure element, just in a new package. An iSIM removes the package entirely. Both rely on the same GSM Association (GSMA) remote provisioning infrastructure, but their hardware trust boundaries, certification paths, and modem integration models are fundamentally different.

1. eSIM: The eUICC as a Discrete Secure Element

An eSIM is formally an eUICC — Embedded Universal Integrated Circuit Card — defined by GSMA SGP.22 (consumer) and SGP.02 (M2M) and standardized at the hardware level by ETSI TS 103 383 and JEDEC MFF2. Physically it is a 6x5mm QFN, 3x3mm WLCSP, or even smaller wafer-level package soldered permanently. You cannot remove it without rework.

Inside is familiar: a 32-bit tamper-resistant MCU (typically ARM SecurCore SC300), 300–800KB secure NVM, hardware crypto accelerators for AES, 3DES, RSA and ECC, a true random number generator, and the SIM OS (Java Card + SIM Toolkit). It speaks the classic UICC interface — ISO 7816-3 T=0/T=1, plus modern eUICC extensions for SPI and I2C to reduce pin count and support 1.8V low-power operation.

What Makes It Remote-Provisionable

Unlike a pSIM, which is provisioned at the factory with one operator profile, an eUICC ships blank with a provisioning profile and a unique EID (32-digit identifier). The trust anchor is a GSMA CI (Certificate Issuer) certificate chain burned during manufacturing and certified under GSMA SAS and Common Criteria EAL4+.

This enables Remote SIM Provisioning (RSP): the ability to download, enable, disable, and delete Profiles — the full operator credential set including IMSI, Ki/OPc, ICCID, file system, and carrier applets — without physical access.

For system designers, integration is straightforward. As explored in our LPDDR5X memory architecture analysis, co-location of secure elements near the baseband matters for signal integrity. The eUICC typically sits on the baseband’s UICC interface, shares a SIM power rail with level shifting, and requires no changes to the application processor.

2. Remote Provisioning Flow: SGP.22 / SGP.32

The consumer RSP architecture (SGP.22 v2.3+) involves four roles: the eUICC, the Local Profile Assistant (LPA) on the device, the SM-DP+ (Subscription Manager Data Preparation) server, and the SM-DS (Discovery Server).

1. Discovery: User scans QR (Activation Code) or the LPA queries SM-DS via EID. The QR encodes SM-DP+ address + matching ID.
2. Authentication: Mutual TLS between eUICC (with CI cert) and SM-DP+. The LPA bridges the eUICC’s ES10b interface over HTTPS.
3. Download: Profile bound to EID is encrypted (SCP03t + Profile Protection) and transferred in Bound Profile Package segments.
4. Installation & Enable: LPA sends ES10b LoadBoundProfilePackage; eUICC decrypts, installs, and sets the profile as enabled. Only one profile is enabled at a time for most handsets (MEP-capable devices allow multiple enabled).

For IoT, GSMA SGP.32 (released 2023) replaces the LPA’s user interaction with the eIM (eSIM IoT Manager) and IPA (IoT Profile Assistant), enabling fleet provisioning via lightweight CoAP/HTTPS without UI.

// SGP.22 Profile Download - LPA to eUICC (ES10b) example
POST https://smdp.io.operator.com/es9plus/getBoundProfilePackage
Headers: { X-Admin-Protocol: gsma/rsp/v2.3.0 }

eUICC Info: {
  "eid": "89051023320000000000012345678901",
  "euiccCiPKId": "A1B2C3...",
  "profilePolicy": "PPR1 allowed"
}

// Response: Bound Profile Package (ASN.1 / DER, SCP03t encrypted)
AT+CSIM=14,"C781..." // Baseband forwards APDU to eUICC
Profile Metadata: { iccid: "894447...", isdp-aid: "A00000055910..." }

This encrypted-by-default model is why app store security review processes cannot inspect carrier profile contents — the Ki never leaves the eUICC or SM-DP+ HSM in cleartext, mirroring modern app attestation design.

3. iSIM: Collapsing the SIM Into the SoC

iSIM (integrated SIM, sometimes called iUICC) pushes integration one step further. Instead of a discrete package, the SIM function is synthesized as hardened logic plus secure NVM inside the cellular modem or SoC die. Qualcomm’s Snapdragon 8 Gen 2 with integrated iSIM, Sony Altair ALT1350, and Kigen/ARM reference designs all demonstrate this.

Architecturally, an iSIM reuses the SoC’s existing security infrastructure:

• Secure Enclave / SPU: The SIM OS runs in an isolated Trusted Execution Environment (TEE) or dedicated security processor, not on a separate MCU. ARM TrustZone + CryptoIsland or Qualcomm SPU provide isolation.
• Secure NVM: Profile data lives in dedicated on-die flash/RRAM or in replay-protected external flash via inline encryption engine, not in discrete EEPROM.
• Clock/Power: No separate SIM VCC/clock/reset pins. The iSIM shares the SoC’s power management IC (PMIC) domain, enabling sub-uA sleep — critical for NB-IoT and RedCap.

The GSMA now certifies iSIMs under SGP.22/32 via the same EAL4+ and SAS requirements, but the certification scope expands to the entire SoC’s physical and logical attack surface. The EID is still present, but now fused at SoC test time.

4. Security and Certification Reality

Both eSIM and iSIM must pass GSMA’s Security Accreditation Scheme (SAS-UP for manufacturing, SAS-SM for subscription management) and a Common Criteria Protection Profile (PP0116 for eUICC). The difference is the attack surface.

A discrete eUICC benefits from physical separation: side-channel and fault-injection resistance is validated on a small, hardened die. An iSIM inherits the SoC’s side-channel footprint — caches, power planes, and debug interfaces must all be hardened and within the TOE (Target of Evaluation). This makes initial iSIM certification longer, but reuse is higher: once a SoC family is certified, all devices using it inherit compliance without re-certifying the SIM component.

Key storage is also stricter. In eUICC, Ki is stored in internal NVM never exposed over the bus. In iSIM, Ki is wrapped by a hardware Unique Key (HUK) fused in eFuses and only unwrapped inside the security enclave. Profile deletion must cryptographically erase keys, not just unlink memory — audited via GSMA’s key destruction tests.

5. Comparison: pSIM vs eSIM vs iSIM

6. Power, Area, and BoM: Why OEMs Care

For a flagship smartphone, moving from pSIM to eSIM saves the tray, gasket, and connector — about 100mm³ of internal volume that designers often reallocate to battery or mmWave antenna clearance. The cost delta is neutral to slightly positive: you add a $0.80–$1.20 eUICC but remove mechanical parts and simplify water resistance (IP68).

iSIM’s value is not in phones but at scale. In a CAT-M1 tracker or smart meter, eliminating the eUICC saves $0.80, 30mm² PCB, two supply rails, and a pick-and-place step. More importantly, it drops deep-sleep current from ~10µA to ~1µA because the SIM can power-gate with the modem. Over ten years on a small cell battery, that is the difference between meeting and missing the lifetime target. Our FPS stability testing shows similar SoC integration wins where eliminating external buses reduces thermal and power variance — the same principle applies to the modem subsystem here.

There is a trade-off: iSIM couples the SIM lifecycle to the SoC lifecycle. You cannot second-source the SIM without re-spinning the SoC, and field failures require board replacement rather than component replacement. For this reason, most smartphone OEMs will stay on eSIM for the next two generations while IoT SoCs adopt iSIM immediately.

7. What This Means for Developers and OEMs

For app developers, eSIM/iSIM is largely transparent — TelephonyManager and carrier entitlement APIs abstract it. However, if your app handles carrier switching, eSIM entitlement, or private APN provisioning, test against both SGP.22 QR flows and SGP.32 eIM flows. Edge cases include Multiple Enabled Profiles (MEP) on Android 13+, where two profiles can be simultaneously active for DSDS without two physical slots.

For device teams, validate modem SIM driver support: baseband must expose ES10x Logical Channel support and handle BIP (Bearer Independent Protocol) over the LPA. Performance benchmarks should also include modem power under provisioning. As with GPU benchmarking with GFXBench, create a repeatable RSP profile download power trace — profile installation can spike modem current to 300mA for 20–40 seconds. Size your PMIC and thermal budget accordingly.

Finally, plan for logistics. EIDs must be captured from the factory and uploaded to your SM-DP+ or carrier inventory. Lost EID mapping is the number one cause of failed zero-touch provisioning in the field.

8. Outlook: SGP.32 and the iSIM Tipping Point

SGP.32 is the catalyst for iSIM adoption. By removing the need for a local UI and allowing the eIM to orchestrate profile downloads over any IP bearer (including unprovisioned bootstrap connectivity), it solves the chicken-and-egg problem of provisioning a sensor that has no user interface.

Expect eSIM to remain dominant in consumer mobile through 2028 — Apple, Google, and Samsung already ship eSIM-only SKUs in the US. iSIM will overtake in LPWAN and RedCap IoT, where bill of materials and microamp sleep current dominate decisions. Long term, the two will coexist: an iSIM for the primary lifecycle profile plus a discrete eUICC for automotive-grade redundancy where two suppliers are mandated.

The plastic SIM is not dying because of convenience. It is dying because security now lives inside the SoC, and remote provisioning finally makes the last removable secure element removable in software instead of metal.