Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.29 EID > EID in RSP Protocols: Discovery, Matching, and Events
💡 Why this matters: The EID is not a static label: it is an active operational identifier woven throughout every major RSP protocol. When a consumer scans a QR code to activate an eSIM, when an IoT device wakes up and polls for pending profiles, when an operator pushes an event notification: the EID is the key that links the request to the correct chip. Understanding where and how the EID appears in RSP protocols illuminates the end-to-end identity plumbing of the eSIM ecosystem.
Key takeaways:
- The EID is used in SM-DS (Subscription Manager Discovery Service) to match pending profiles to specific eUICCs
- ES11 polling uses the EID to query the SM-DS for profiles awaiting download
- During ES8+ profile download, the EID binds the profile to the correct eUICC through ISD-R operations
- Event registration uses the EID to subscribe specific eUICCs to push notifications from SM-DS
- SGP.29 references SGP.01, SGP.02, SGP.21, and SGP.22 as the defining RSP documents where the EID is operationalised
- The EID’s use extends across both consumer (SGP.22) and IoT (SGP.32) architectures
SGP.29 Section 6 explicitly states: “The EID is the eUICC Identifier used in the context of Remote SIM Provisioning and Management of the eUICC as defined in [SGP.01], [SGP.02], [SGP.21] and [SGP.22].” This article traces how the EID flows through these specifications in practice.
The EID features in both the original M2M architecture (SGP.01/SGP.02) and the Consumer architecture (SGP.21/SGP.22):
┌─────────────────────────────────────────────────────────────────┐
│ Consumer RSP Architecture │
│ (SGP.21 / SGP.22) │
│ │
│ ┌─────────┐ ES11 ┌──────────┐ ES12 ┌─────────┐ │
│ │ LPA │◄────────────►│ SM-DS │◄────────────►│ SM-DP+ │ │
│ │ (in │ EID-based │Discovery │ Event │ Profile │ │
│ │ Device)│ polling │ Service │ Registry │ Server │ │
│ └────┬────┘ └──────────┘ └────┬────┘ │
│ │ │ │
│ │ ES10 (local) ES8+ │ │
│ │ EID context EID in │ │
│ │ binding │ │
│ ┌────┴────┐ ┌────┴────┐ │
│ │ eUICC │◄────────── Profile Download ────────│ SM-DP+ │ │
│ │ (EID) │ (EID-authenticated) │ │ │
│ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────────────┘
The SM-DS (Subscription Manager Discovery Service) is the central directory that matches profiles waiting to be downloaded with the eUICCs that should receive them.
┌──────────────────────────────────────────────────────────────────┐
│ SM-DP+ prepares a profile for download │
│ │ │
│ ▼ │
│ SM-DP+ registers Event with SM-DS: │
│ • EID = 12345000000000000000000000000133 │
│ • Event Type = Profile Download Available │
│ • SM-DP+ Address = dp.example.com │
│ │ │
│ ▼ │
│ SM-DS stores: {EID → [Pending Events]} │
│ │ │
│ ▼ │
│ LPA polls SM-DS (ES11): "Any events for EID 12345...0133?" │
│ │ │
│ ▼ │
│ SM-DS responds: "Yes → Event from dp.example.com" │
│ │ │
│ ▼ │
│ LPA initiates ES8+ download from SM-DP+ │
└──────────────────────────────────────────────────────────────────┘
The EID is the primary lookup key in the SM-DS. Without the EID, the SM-DS has no way to associate a pending profile with the correct chip.
This is why SGP.29 Principle EID.P02 mandates global uniqueness : if two eUICCs shared the same EID, the SM-DS would route profiles to the wrong device, with potentially catastrophic security consequences (e.g., an operator profile being downloaded onto an attacker’s device).
ES11 is the interface between the LPA (Local Profile Assistant) and the SM-DS. The LPA queries the SM-DS on behalf of the eUICC using the EID:
LPA → SM-DS (ES11):
GET /gsma/rsp2/es11/handle-ds-event
{
"eid": "12345000000000000000000000000133",
"lpaSignature": "..."
}
SM-DS → LPA (ES11 Response):
{
"pendingEvents": [
{
"eventId": "abc-123",
"rspServerAddress": "dp.example.com"
}
]
}
The LPA periodically polls the SM-DS (or is triggered by the user opening the eSIM management UI). Each poll includes the EID, and the SM-DS responds with any pending events for that EID.
In the IoT architecture, the IPA (IoT Profile Assistant) performs an analogous function over ESipa, using the EID to poll the SM-DS for IoT profiles.
Once the LPA has been directed to the correct SM-DP+ (via SM-DS discovery or QR code), the ES8+ profile download begins. The EID is central to the mutual authentication that precedes any profile transfer.
SM-DP+ eUICC
│ │
│ [Knows EID from discovery/QR] │
│ │
│ ES8+.GetBoundProfilePackage ──────────▶│
│ (includes expected EID) │
│ │
│ ┌──────────────┴──────────────────┐
│ │ eUICC verifies: │
│ │ • "Is this profile for my EID?" │
│ │ • "Is SM-DP+ certificate valid?"│
│ │ • "Does the binding match?" │
│ └──────────────┬──────────────────┘
│ │
│ ◀─────────── eUICC responds with │
│ eUICC signature + EID │
│ │
│ ┌───────────┴──────────────────────────┐
│ │ SM-DP+ verifies: │
│ │ • "Does EID match expected?" │
│ │ • "Is eUICC certificate valid?" │
│ │ • "Is signature correct?" │
│ └───────────┬──────────────────────────┘
│ │
│ Bound Profile Package ────────────────▶│
│ (encrypted to eUICC's public key) │
│ │
The EID acts as an identity anchor throughout this exchange. The SM-DP+ binds the profile to a specific EID, and the eUICC confirms the profile was intended for it.
Beyond polling, the SM-DS also supports event-driven notifications. An SM-DP+ can register events for specific EIDs:
| Event | Trigger | EID Role |
|---|---|---|
| Profile Download Available | SM-DP+ has prepared a profile | EID identifies the target eUICC |
| Profile State Change | Profile enabled/disabled/deleted | EID links the event to the chip |
| Remote Management | Operator pushes management command | EID routes the command |
SM-DP+ → SM-DS (ES12):
REGISTER Event
Event ID: evt-xyz-001
EID: 12345000000000000000000000000133
Event Type: Profile Download Available
RSP Address: dp.example.com
Expiry: 2026-07-05T00:00:00Z
SM-DS stores the event and serves it on next ES11 poll for that EID.
The EID’s role spans all four core RSP specifications:
| Specification | EID Usage Context |
|---|---|
| SGP.01 | Defines the RSP architecture where EID is the eUICC’s identity |
| SGP.02 | M2M technical specification: EID used in profile download and management for M2M devices |
| SGP.21 | Consumer architecture: EID as the identity anchor in the LPA-based workflow |
| SGP.22 | Consumer technical specification: EID in ES8+, ES11, and event registration operations |
| SGP.32 | IoT technical specification: EID in IPA-based discovery and download (analogous to SGP.22 but for IoT) |
Based on GSMA SGP.29 v1.1 (22 March 2024) : EID Definition and Assignment Process, Section 6 (EID Usage), with protocol context from SGP.21, SGP.22, and SGP.32
| ← Previous: EID Assignment: How Manufacturers Get Their Allocations | Section Index | Next: EID Security: Privacy, Tracking, and GSMA Governance → |