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.02 M2M RSP > Profile Lifecycle: Enable, Disable, Delete, and Fall-Back
You’ve downloaded a Profile onto an eUICC inside a sealed water meter. It’s sitting there, disabled, waiting. Now the real work begins: this Profile will be enabled, disabled, maybe deleted, and possibly resurrected through Fall-Back, all over the course of a deployment that might outlast the careers of the engineers who provisioned it.
Nobody’s going to unscrew that meter to swap a SIM. Every operation happens remotely, through an OTA channel the SM-SR owns. And every operation follows a pattern the spec repeats with almost obsessive consistency: Normal Case, Connectivity Failure Case, roll-back. Get used to that pattern; SGP.02 never stops thinking about what happens when things go wrong.
Before we dive in: this article assumes you understand the SGP.02 architecture (roles, interfaces), the eUICC’s internal security domain structure (ISD-R, ISD-P, ECASD), and how a Profile gets downloaded. Articles 1–5 cover those foundations.
Not everyone who wants to toggle a Profile has a direct line to the SM-SR. SGP.02 defines three initiation paths, and which one you use depends on who you are and what relationship you have with the infrastructure.
Path 1: Operator via ES4 (direct SM-SR). The Operator calls ES4.EnableProfile (or Disable, or Delete). The SM-SR receives it, checks its policies, and forwards the command to the eUICC over ES5. This is the straightforward case: one call, one intermediary. It’s how a full-service MNO managing its own fleet typically works.
Path 2: Operator via SM-DP relay (ES2 → ES3 → ES5). Some Operators interact primarily with their SM-DP: the same entity that prepared the Profile in the first place. In this path, the Operator calls the SM-DP (ES2), which relays the request to the SM-SR (ES3), which then contacts the eUICC (ES5). The SM-DP acts as a translator between the profile-preparation world and the lifecycle-management world.
Path 3: M2M SP via ES4. Fleet managers and enterprise customers don’t always want to call the Operator every time they need a profile change. With prior authorisation from the Profile-owning Operator (granted via PLMA; see Article 9), an M2M Service Provider can call the SM-SR directly through ES4. The utility company managing thousands of meters gets to drive, while the mobile operator retains veto power through policy rules.
All three paths converge at the eUICC: the ISD-R receives the command via ES5 (SMS, HTTPS, or CAT_TP), checks POL1, executes the operation, and notifies the SM-SR. The path that got the command there doesn’t change what happens on the card.
| Operation | Operator (ES4) | Operator via SM-DP (ES2→ES3→ES5) | M2M SP (ES4) |
|---|---|---|---|
| Enable | ES4.EnableProfile |
ES2.EnableProfile → ES3.EnableProfile |
ES4.EnableProfile (with PLMA) |
| Disable | ES4.DisableProfile |
ES2.DisableProfile → ES3.DisableProfile |
ES4.DisableProfile (with PLMA) |
| Delete | ES4.DeleteProfile |
ES2.DeleteProfile → ES3.DeleteProfile |
ES4.DeleteProfile (with PLMA) |
| Master Delete | Out of scope (ES4 by Initiator) | Via SM-DP authorisation | Not applicable |
Enabling is the operation that makes a Profile’s NAA (Network Access Application) and file system visible over the UICC-Terminal interface. Only one Profile can be enabled at a time; if you enable Profile B, Profile A gets automatically disabled. There’s no graceful handoff and no confirmation dialog. The ISD-R just does it.
The Normal Case flow (SGP.02 §3.2.1):
ES4.EnableProfile(eid, iccid) (or ES2.EnableProfile through the SM-DP)ES5.STORE DATA command to the ISD-R, typically via SMSES5.DELETE commandThis is the Connectivity Failure Case (§3.2.2), and it’s where SGP.02 earns its reputation for paranoia-that-pays-off. If the newly enabled Profile can’t attach to the network, or if the notification procedure fails, the eUICC doesn’t just shrug and leave the device stranded:
A failed profile switch in a device nobody can physically reach would otherwise mean permanent disconnection. The automatic roll-back is the spec’s answer to that nightmare.
Disabling (§3.4) makes a Profile unselectable while leaving it intact on the card. The flow mirrors enabling: SM-SR checks, OTA command, ISD-R executes, notification, EIS update; but with one difference that changes everything:
When you disable a Profile, the eUICC automatically enables the Fall-Back Profile.
Think about why. If you disable the only enabled Profile and don’t turn anything else on, the device goes dark. No connectivity. No OTA channel. Your only option is a truck roll; and for devices in basements, engine compartments, or remote weather stations, that might not even be practical. So SGP.02 mandates immediate failover to whatever Profile carries the Fall-Back Attribute.
Two more things happen during disable:
The spec explicitly notes that POL1 and POL2 “MAY have different content. As a consequence, both the eUICC and the SM-SR have to ensure the ISD-P deletion based on their respective Policy.” One side might delete while the other doesn’t. That’s not a bug; it’s intentional redundancy.
Profile Deletion (§3.6, §3.7) permanently removes the ISD-P and everything inside it: NAA, file system, keys, applets, metadata. It can be triggered three ways:
ES4.DeleteProfileES2.DeleteProfile → ES3.DeleteProfile → ES5 commandsThe on-card flow is simple: SM-SR sends ES5.DELETE targeting the disabled Profile’s ISD-P. ISD-R checks POL1. If it permits, the ISD-P gets wiped. SM-SR updates the EIS. You can’t delete the currently enabled Profile; disable it first. The deletion is permanent and irreversible. No undo.
Sometimes a Profile needs to go but the rules say it can’t. The owning Operator went bankrupt. The policy was set too restrictively. Nobody with authority is reachable to change it. These are orphaned Profiles, and they’d permanently consume space on the eUICC if SGP.02 hadn’t thought ahead.
The Master Delete procedure (§3.10) solves this with a cryptographically authorised Delete Token issued by the SM-DP:
ES5.MasterDelete with the token to the ISD-ROne hard limit: you can’t Master Delete the Fall-Back Profile. The device always keeps at least one path back to connectivity.
Once you’ve read a few SGP.02 procedures, you start to notice the same failure-handling skeleton underneath all of them. Enable, disable, delete; they all share it:
This pattern is what makes remote management of inaccessible devices viable. Every operation has a built-in escape hatch.
The three-path architecture is what makes SGP.02 flexible enough for diverse M2M deployments. A utility company acting as its own M2M SP can manage its meter fleet directly. The mobile operator retains ultimate control through PLMA and POL1/POL2 policy rules. And every operation, no matter who initiated it or through which path, converges on the same on-card procedure with the same failure handling.
Based on GSMA SGP.02 v4.2 (07 July 2020): Remote Provisioning Architecture for Embedded UICC Technical Specification, §3.2–3.7, §3.10
| ← Previous: Profile Download: ISD-P Creation, SCP03, and Encrypted Delivery | Section Index | Next: SM-SR Change: Handover, ES7 Interface, and EIS Migration → |