eSIM vs Physical SIM — Technical Trade-offs
The shift from physical SIM to eSIM (eUICC) is one of the biggest changes in mobile technology. But from a technical perspective, what are the real differences? This comparison focuses on the developer and system integrator perspective — profile provisioning, security architecture, and hardware implications.
Technical Comparison
| Feature | Physical SIM (UICC) | eSIM (eUICC) |
|---|---|---|
| Form Factor | Removable (2FF/3FF/4FF) | Soldered MFF2 or iSIM (integrated) |
| Profile Switching | Physical swap required | Remote download via RSP (GSMA SGP.22) |
| Multiple Profiles | 1 per card | Multiple profiles (typically 2-8) |
| Security Architecture | Single security domain | ISD-R + ISD-P hierarchy (GlobalPlatform) |
| Device Size Impact | SIM tray + connector required | No tray — saves PCB space |
| Water Resistance | SIM tray is ingress point | No opening — better sealing |
| Carrier Lock-in | Low — swap SIM | Higher — profile policy can restrict |
| Remote Provisioning | No | Yes (SM-DP+, LPA) |
| IoT/M2M Suitability | Poor (physical access needed) | Excellent (remote lifecycle mgmt) |
| Cost per Unit | ~$0.10-0.30 | ~$0.50-1.50 (MFF2), ~$0 (iSIM) |
Developer Implications
eSIM requires understanding GSMA SGP.22
Working with eSIM means dealing with LPA (LPAd + LPAe), SM-DP+, BPP (Bound Profile Package), and the ES10a/b/c APDU interface. Physical SIM development is simpler — you read/write files. eSIM development requires understanding the full GSMA RSP stack.
We have a full eSIM & eUICC Architecture Guide with the details.
Physical SIM is still dominant for testing
For smart card development and testing, physical SIM cards remain more accessible. You can buy blank programmable SIM cards, use PC/SC readers, and test USIM applets directly. eSIM testing requires eUICC-capable hardware and SM-DP+ sandbox access.
Security Deep Dive
Physical SIM cards rely on a single security domain — the UICC OS manages all keys and access control internally. If you need to install a new application or update keys, you must physically insert the card into a reader and authenticate via GlobalPlatform SCP.
eSIM introduces a two-tier security model: the ISD-R (Issuer Security Domain — Root) acts as a profile manager, while each ISD-P (Issuer Security Domain — Profile) is an isolated container holding a complete carrier profile with its own keys, USIM applets, and filesystem. This isolation means a compromised profile cannot access another profile's secrets — a significant improvement over single-domain UICC designs.
However, eSIM adds new attack surfaces: the RSP (Remote SIM Provisioning) channel itself. The SM-DP+ server must be trusted, and the BPP download uses mutual TLS + symmetric key authentication. A misconfigured SM-DP+ or compromised signing key could allow profile injection attacks — a risk class that does not exist with physical SIM.
Cost & Supply Chain Analysis
For low-volume projects and prototyping, physical SIM cards are cheaper and easier to source. Blank programmable UICC cards cost roughly $0.10–0.30 per unit and are available from standard electronics distributors.
eSIM MFF2 chips cost $0.50–1.50 per unit in small quantities, but the real cost is the infrastructure overhead: you need an SM-DP+ subscription (or rented service), GSMA certification for SGP.22 compliance, and test eUICC hardware. For IoT deployments exceeding 10,000 units, eSIM becomes cost-effective due to remote provisioning savings — no truck rolls, no physical card swaps for carrier changes.
iSIM (Integrated SIM) takes this further by embedding the eUICC into the main SoC's secure enclave, eliminating the dedicated chip entirely. This reduces BOM cost to near zero but requires close partnership with chipset vendors.
Migration Path: When to Switch
If your project involves consumer mobile devices (phones, tablets, wearables), eSIM is the clear direction — GSMA SGP.22 is mature and carrier support is broad. Start with the LPA (Local Profile Assistant) interface on Android or iOS.
For IoT/M2M deployments, evaluate eSIM only if you need remote carrier switching at scale. If devices are deployed in fixed locations with a single carrier, physical SIM remains simpler and cheaper.
For smart card development and testing, stay with physical SIM. PC/SC readers, blank cards, and direct APDU access via pyscard or javax.smartcardio are far more productive than debugging eUICC profile management for prototyping.
Related
eSIM & eUICC Architecture Guide | APDU Command Builder | T=0 vs T=1 Protocol