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.22 Consumer RSP > Notifications and Post-Install: Keeping Operators in the Loop
💡 Why this matters: Profile installation is just the beginning. Operators need to know what happened: did it succeed? Was the profile enabled? Was it later deleted? The notification framework is the eUICC’s reporting system, and it’s what makes eSIM a manageable ecosystem rather than a one-shot download. For companion devices and profile transfers, Activation Code Retrieval closes the loop.
Key takeaways:
- Two types of notifications: Profile Installation Results (immediate, SM-DP+) and Other Notifications (deferred, configured in profile metadata)
- Notification types include: Install, Enable, Disable, Delete: each with a globally incrementing Sequence Number
- The LPA retrieves pending notifications via ES10b, sends them to SM-DP+ via ES9+.HandleNotification, then removes them from the eUICC
- ES6.UpdateMetadata is the operator’s post-install OTA channel: it can update profile metadata, PPRs, and Notification Configuration
- Activation Code Retrieval (ACR, section 3.1.7) lets a companion device re-download a profile that was originally installed elsewhere
- The LPAe handles notifications slightly differently from LPAd: with LPAe, there’s no ES10b boundary to cross
When a profile is installed, enabled, disabled, or deleted, someone needs to know. The operator who owns the profile, the SM-DP+ that delivered it, and potentially other backend systems all need to update their state. SGP.22’s notification framework (section 3.5) provides a standardised, reliable mechanism for the eUICC to report profile lifecycle events to the ecosystem.
Section 3.5 defines two categories of notifications, managed separately by the eUICC:
Generated immediately during the profile download and installation procedure (section 3.1.3). This is the eUICC’s definitive answer to “did the installation work?” It includes:
The Profile Installation Result is delivered to the SM-DP+ via ES9+.HandleNotification immediately after installation. It is also the trigger for the SM-DP+ to call ES2+.HandleDownloadProgressInfo to the operator, completing the download lifecycle.
The eUICC stores the Profile Installation Result persistently until the LPA explicitly deletes it after successful delivery. If storage is exhausted, the eUICC deletes the oldest results first (by Sequence Number).
These are deferred notifications generated when a profile management operation completes. They’re configured per-profile through the Notification Configuration Information in the profile metadata (set during ES8+.StoreMetadata).
The notification configuration specifies:
When the specified operation completes successfully, the eUICC generates a notification with:
Sequence Number semantics: There is a single Sequence Number counter per eUICC, used across all profiles and both notification types. It increments each time any notification is generated. It survives eUICC Memory Reset and eUICC reset: this is the eUICC’s monotonic clock for event ordering.
The flow for Other Notifications is a store-and-forward system:
Profile Management Operation completes
│
▼
eUICC generates Notification
(Sequence Number++, signed)
│
▼
Notification stored in eUICC NV memory
│
▼
LPA polls: ES10b.RetrieveNotificationsList
│
▼
LPA establishes TLS to SM-DP+
│
▼
LPA sends: ES9+.HandleNotification(Notification)
│
▼
SM-DP+ acknowledges
│
▼
LPA calls: ES10b.RemoveNotificationFromList(SeqNumber)
│
▼
eUICC deletes Notification from storage
Key design choices in this flow:
Best-effort delivery: The LPA sends notifications when connectivity is available. There’s no guarantee of immediate delivery: the notification sits on the eUICC until the LPA can reach the SM-DP+.
Sequential per-recipient: Notifications to the same SM-DP+ are sent in Sequence Number order, one at a time. The LPA waits for acknowledgement before sending the next. This preserves ordering guarantees for the recipient.
Parallel across recipients: Notifications to different SM-DP+ addresses can be sent in parallel. A profile from Vodafone and a profile from T-Mobile can have their notifications delivered concurrently.
Storage management: If the eUICC runs out of notification storage, it deletes the oldest notifications first (lowest Sequence Number). This means a long-offline device will eventually lose old notifications: the system is designed for eventual consistency, not guaranteed delivery.
A particularly interesting case is when enabling a new profile implicitly disables the currently enabled one. Section 3.5 specifies:
When an Enable Profile is successfully performed and the currently enabled Operational Profile is implicitly disabled as a consequence of the enable Profile, the Notifications on both the disable Profile and enable Profile SHALL be generated, provided that each Operation is indicated in the Notification Configuration List.
This means a single user action (switching profiles) can generate two notifications: one for the profile being disabled, one for the profile being enabled. Each goes to its own configured recipient: so Vodafone learns that its profile was disabled, and T-Mobile learns that its profile was enabled.
Once a profile is enabled, the operator has a direct OTA channel to the eUICC: ES6 (section 5.4). The primary ES6 function in v2.7 is UpdateMetadata (5.4.1).
This function allows the operator to remotely update:
The UpdateMetadata function uses the MNO-SD’s secure channel (SCP80 or SCP81), not the RSP key hierarchy. This is the same OTA infrastructure operators have used for decades to manage traditional SIM cards. The difference is that with eSIM, the operator can also update PPRs: something that was impossible with physical SIMs.
PPR update constraints (2.9.3.2): When UpdateMetadata modifies PPRs, the eUICC re-verifies them against the RAT. An operator cannot add PPR1 to a profile post-install if the RAT doesn’t authorise it. The update is atomic: if any new PPR fails verification, the entire update is rejected.
When the LPA runs inside the eUICC (LPAe, covered in article 07), the notification flow changes subtly. The LPAe doesn’t have an ES10b interface: those function calls become internal API invocations within the eUICC OS.
The primary difference is efficiency: no APDU exchanges, no serial transport. The LPAe can directly read the notification list, establish HTTPS to the SM-DP+, send the notification, and remove it: all within the eUICC. This reduces both latency and the risk of transport-layer failures.
However, the LPAe still needs IP connectivity through the device (via BIP), so the device must be online for notification delivery.
A companion feature to the notification framework is Activation Code Retrieval (section 3.1.7, 3.1.8, 4.9). This solves a specific problem: how does a companion device re-download a profile that was originally provisioned on a primary device?
A user buys a cellular smartwatch. They scan a QR code on their phone, which downloads an eSIM profile for the watch. Now they upgrade to a new watch. How does the profile move?
With physical SIMs, you just move the card. With eSIM, the profile is bound to the original eUICC. The answer is ACR: the SM-DP+ can provide a new Activation Code that lets the profile be re-downloaded onto a different eUICC.
ACR-0-<ICCID> (for retrieval) or ACR-1-<ICCID> (for availability check)The security model is straightforward: the SM-DP+ only provides the new Activation Code if it has received the Delete Notification for the original installation. The profile can only exist on one eUICC at a time. This is enforced server-side: the SM-DP+ tracks profile state per EID.
Before attempting the actual retrieval, the LPA can first check whether ACR is available using request type “1”. This is a lightweight call that returns success/failure without generating the Activation Code. It lets the UI show a “Transfer eSIM” button only when the transfer is actually possible.
For operators: Your OTA platform needs to handle UpdateMetadata for eSIM profiles. This is the same SCP80/SCP81 infrastructure you use for SIM OTA: but you now have additional metadata fields (PPRs, notification config) to manage.
For SM-DP+ operators: HandleNotification is a critical endpoint. It’s called for every profile lifecycle event. Design for high availability: if HandleNotification is down, notifications accumulate on the eUICC and eventually get evicted.
For device manufacturers: The notification delivery loop needs to run regularly. If your LPA only checks for notifications once a day, operators won’t learn about profile state changes in a timely manner. Consider triggering notification delivery after every profile management operation.
For companion device scenarios: ACR is the missing link for profile transfer. Combined with the companion device architecture (Annex C, covered in article 11), it enables seamless eSIM migration between devices.
The notification framework closes the loop between the eUICC and the ecosystem. Without it, profile management would be a fire-and-forget operation: the operator would never know if the profile was actually enabled or if it was later deleted. With it, eSIM becomes a fully observable, manageable system. In the final article of this series, we’ll explore the SM-DS discovery service and how it enables companion device provisioning.