Guide

eSIM RSP Deep Dive: The Technology Powering Remote SIM Provisioning

TravelGo 2026-05-27
eSIM RSP Deep Dive: The Technology Powering Remote SIM Provisioning

The GSMA RSP Architecture: Core Components

Remote SIM Provisioning (RSP) is the architectural backbone that makes eSIM technology possible. Defined by GSMA's SGP specifications, the RSP ecosystem comprises four fundamental components that work in concert. First, the eUICC (embedded Universal Integrated Circuit Card) — the physical hardware chip soldered onto a device's motherboard — serves as the secure element capable of hosting multiple operator profiles simultaneously. Unlike traditional SIM cards, the eUICC runs a specialized operating system that supports profile isolation, ensuring each carrier's credentials remain cryptographically segregated. Second, the Subscription Manager Data Preparation (SM-DP+) server acts as the profile factory and delivery hub. It creates, encrypts, stores, and delivers operator profiles to eUICCs over-the-air. The SM-DP+ is operated by either the carrier or a trusted third-party GSMA-certified facility, and every interaction is protected by a mutual TLS channel anchored in a Public Key Infrastructure (PKI). Third, the Local Profile Assistant (LPA) runs on the consumer device itself — as a system-level application on smartphones, tablets, or wearables — bridging the gap between the end user and the SM-DP+. The LPA handles profile discovery, download orchestration, and local profile management (enable, disable, delete). Finally, the Subscription Manager Discovery Server (SM-DS) provides an optional but critical push-notification mechanism, alerting the LPA when a new profile is awaiting download, eliminating the need for constant polling.

The Profile Lifecycle: Creation to Deletion

Every eSIM profile follows a meticulously defined lifecycle governed by GSMA SGP.22 (Consumer) and SGP.02 (M2M) specifications. The journey begins with Profile Creation at the SM-DP+, where an operator's network credentials — including the IMSI, authentication keys (Ki), OTA keys, and file system structure — are bundled into a standardized format called a Profile Package. This package is then encrypted using a one-time symmetric key, which itself is wrapped with the target eUICC's public key, ensuring end-to-end protection. The profile remains dormant in the 'Created' state until the end user initiates activation, typically by scanning a QR code containing an activation token. During Profile Download, the LPA establishes a secure HTTPS session with the SM-DP+ using TLS 1.2 or higher with mutual authentication. The profile is transmitted in a series of secured packets using ES8+ interface commands. Once fully written to the eUICC's memory and integrity-verified, the profile enters the 'Disabled' state. The user can then Enable the profile, which triggers the eUICC to load those credentials into its active runtime, register on the carrier's network, and begin normal operation. Profiles can later be Disabled (returned to dormant storage) or permanently Deleted, which triggers a secure erasure process and a notification back to the SM-DP+ via the ES9+ interface. This lifecycle guarantees that profiles never exist in an ambiguous state — every transition is atomic, logged, and cryptographically bound.

Security by Design: PKI, Certificates, and Mutual Auth

The security model underpinning eSIM RSP is one of the most sophisticated in consumer technology. At its core lies a multi-tier Public Key Infrastructure (PKI) defined by GSMA's Security Accreditation Scheme (SAS). Every eUICC leaves the factory with a unique private key and a corresponding digital certificate — the eUICC Certificate (EUM Certificate) — signed by the chip manufacturer (EUM), which in turn is certified by a GSMA root Certificate Issuer (CI). This chain of trust ensures that any SM-DP+ can cryptographically verify the authenticity of an eUICC before delivering a profile. Conversely, SM-DP+ servers must possess certificates signed by a GSMA-certified CI, allowing the eUICC to authenticate the server. This mutual TLS authentication eliminates man-in-the-middle attacks at the hardware level. Profile delivery uses a dual-layer encryption scheme: the profile itself is encrypted with a randomly generated symmetric Profile Protection Key (PPK), and the PPK is asymmetrically encrypted with the eUICC's public key. Even if an attacker intercepts the TLS stream, the inner profile payload remains opaque without the eUICC's private key. Additionally, each profile download session requires a one-time activation token (matching an AC_Token on the SM-DP+), preventing replay attacks and unauthorized profile retrieval. GSMA mandates regular SAS audits of all entities in the chain — from chip fabrication facilities to SM-DP+ data centers — ensuring the entire infrastructure maintains hardened physical and logical security postures.

Consumer vs. M2M RSP: Two Architectures, One Goal

GSMA defines two distinct RSP architectures tailored to fundamentally different use cases. The Consumer architecture (SGP.22) is designed for devices with rich user interfaces — smartphones, tablets, and smartwatches — where the end user actively initiates and manages profile operations. It employs a 'pull' model: the LPA on the device pulls profiles from the SM-DP+ upon user request. This architecture assumes the user is present and interactive, and the device has adequate processing power, memory, and battery life to run an LPA. In contrast, the M2M (Machine-to-Machine) architecture defined in SGP.02 serves industrial IoT scenarios — smart meters, automotive telematics units, asset trackers — where no human operator is available, the device may be power-constrained, and connectivity is intermittent. The M2M model uses a 'push' model orchestrated by a central SM-SR (Subscription Manager Secure Routing) server that proactively manages profiles on fleets of devices. The SM-SR handles the entire profile lifecycle — download, enable, disable, delete — without device-side user interaction. This architectural divergence explains why a consumer-grade smartwatch and an industrial sensor both use 'eSIM' yet operate on fundamentally different provisioning stacks. GSMA is now working on a unified 'IoT RSP' specification (SGP.32) that bridges these two worlds, bringing lightweight LPAs to constrained devices while maintaining centralized orchestration — a critical evolution as eSIM scales from billions of consumer devices to tens of billions of IoT endpoints.