eSIM RSP Knowledge Base

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.

---

Project maintained by AlexsCodingAgent Hosted on GitHub Pages — Theme by mattgraham

Remote Profile Management: RPM Initiation, Download, and Execution

🏠 eUICC.tech > SGP.22 v3.x Unified RSP > Remote Profile Management: RPM Initiation, Download, and Execution

💡 Why this matters: In SGP.22 v2.x, profile lifecycle management (enable, disable, delete, update metadata) is entirely local: the end user must manually trigger every operation through the device UI. There’s no way for an operator to remotely manage a profile they own. Remote Profile Management (RPM) changes this: an operator can issue lifecycle commands through the SM-DP+, which packages them into an RPM Package, delivers them to the eUICC, and reports the results back. This unlocks fleet management, operator-initiated profile switches, remote metadata updates, and contact with the Profile Content Management Platform: all without touching the device.

Key takeaways:

• RPM is a v3.x-only feature (#SupportedForRpmV3.X.Y#), initiated by the Operator via the ES2+ interface
• The Operator sends an rpmScript to a Managing SM-DP+, which creates an RPM Package containing one or more RPM Commands
• RPM Commands: Enable, Disable, Delete, ListProfileInfo, UpdateMetadata, Contact PCMP
• RPM has three phases: Initiation (Operator → SM-DP+), Download (LPA pulls RPM Package from SM-DP+), and Execution (eUICC processes commands and returns results)
• Each RPM Command requires Confirmation Request enforced by the LPA: the end user must approve
• RPM Packages can be chained using rpmPending for multi-round operations
• The continueOnFailure flag allows graceful handling of individual command failures within a package

---

What RPM Solves

In v2.x, if an operator wants to disable a profile (e.g., because the subscriber stopped paying), they must:

1. Hope the end user disables it themselves
2. Or use OTA (Over-The-Air) mechanisms via ES6, which are limited and profile-dependent

RPM gives operators a direct, standardised path to manage profiles remotely:

• Enable/Disable: Switch profiles on or off without end-user initiation
• Delete: Remove a profile entirely
• Update Metadata: Change profile name, icon, or other metadata remotely
• Contact PCMP: Trigger a Profile Content Management session (e.g., to provision new applets or update profile contents)
• List Profile Info: Query the current state of installed profiles

---

The RPM Architecture

Key Concepts

Concept	Description
Managing SM-DP+	An SM-DP+ authorised to perform RPM on a specific Profile. A Profile MAY have multiple Managing SM-DP+s
RPM Package	An ASN.1-encoded sequence of RPM Commands, generated by the SM-DP+ and delivered to the eUICC
RPM Command	A single lifecycle operation: Enable, Disable, Delete, ListProfileInfo, UpdateMetadata, or Contact PCMP
rpmScript	The Operator’s request to the SM-DP+, specifying which RPM Commands to execute against which Profiles
RPM Command Result	The eUICC’s response for each executed command, packaged into the Load RPM Package Result

The RPM Package Structure

RpmPackage ::= SEQUENCE OF RpmCommand

RpmCommand ::= SEQUENCE {
    continueOnFailure    NULL OPTIONAL,
    rpmCommandDetails    CHOICE {
        enable              SEQUENCE { iccid Iccid },
        disable             SEQUENCE { iccid Iccid },
        delete              SEQUENCE { iccid Iccid },
        listProfileInfo     ListProfileInfo,
        updateMetadata      SEQUENCE { iccid Iccid, updateMetadataRequest UpdateMetadataRequest },
        contactPcmp         SEQUENCE { iccid Iccid, dpiRpm UTF8String OPTIONAL }
    }
}

The RPM Package is limited to 1057 bytes maximum (value part). If more commands are needed, the SM-DP+ can chain multiple RPM Packages using rpmPending.

---

Phase 1: RPM Initiation (Section 3.7.1)

The Operator initiates RPM by calling ES2+.RpmOrder on a Managing SM-DP+:

1. Operator optionally generates a MatchingID : this acts as the activation token the LPA uses to discover the RPM Package
2. Operator calls ES2+.RpmOrder with:
   • eid : the target eUICC
   • rpmScript : the RPM Commands to execute
   • Optional MatchingID
   • Optional Root SM-DS and Alternative SM-DS addresses
3. SM-DP+ verifies that the Operator is the Profile Owner of all targeted Profiles
4. SM-DP+ prepares the RPM Package : building the ASN.1 structure from the rpmScript
5. SM-DP+ registers an Event : either on the specified SM-DS or on a Default SM-DP+ address
6. SM-DP+ returns the MatchingID to the Operator

The Operator can then deliver the MatchingID to the end user (via SMS, email, app notification, or the Push Service) to trigger the download.

---

Phase 2: RPM Download (Section 3.7.2)

The LPA retrieves the RPM Package through one of four paths:

1. Polling Address (from Profile Metadata) : the LPA detects a pending RPM by polling the SM-DP+ address stored in the profile’s metadata
2. SM-DS Event : the LPA retrieves an Event from the SM-DS (traditional v2.x discovery path)
3. Default SM-DP+ : the LPA contacts the Default SM-DP+ address
4. rpmPending chaining : a previous RPM Package indicated more commands are pending

Once the LPA connects to the SM-DP+:

1. Common Mutual Authentication establishes a secure session
2. SM-DP+ builds smdpSigned3 containing {TransactionID, RpmPackage, [rpmPending]}
3. SM-DP+ signs the data and returns it to the LPA
4. LPA checks the RPM Package against Profile Policy Rules (PPRs), obtains User Consent and User Confirmation
5. If the end user rejects, the LPA cancels the session (Common Cancel Session procedure)
6. If the end user accepts, the procedure continues to RPM Execution

The LPA is required to check each RPM Command against PPRs before asking for user consent. If a PPR forbids the operation (e.g., a profile has “disable not allowed”), the LPA rejects the corresponding command.

---

Phase 3: RPM Execution (Section 3.7.3)

The LPA delivers the RPM Package to the eUICC via ES10b.LoadRpmPackage:

1. The eUICC executes RPM Commands sequentially in the received order
2. For each command:
   • If execution succeeds, the eUICC records the success result
   • If execution fails:
     • If continueOnFailure is present → the eUICC continues to the next command
     • If continueOnFailure is absent → the eUICC stops processing and returns the error
3. Atomicity is per-command : each RPM Command is processed atomically, but if power is lost mid-package, the eUICC may be unable to process remaining commands (indicated by interruption in the result)
4. The eUICC generates the Load RPM Package Result (LoadRpmPackageResult) containing:
   • Sequence of RpmCommandResult for each executed command
   • Optional interruption flag if execution was interrupted
   • Signatures for integrity verification

RPM Command Processing Rules

Special constraints apply to command sequencing within an RPM Package:

• Enable/Disable limits: An RPM Package may contain at most one Enable command, one Disable command, or one Disable followed by one Enable. The eUICC MAY reject subsequent Enable/Disable commands with commandsWithRefreshExceeded
• Contact PCMP must be last: The Contact PCMP command SHALL NOT be followed by any other RPM Command. Subsequent commands are rejected with commandAfterContactPcmp
• Test Profiles excluded: RPM Commands targeting Test Profiles SHALL be rejected: RPM is for Operational Profiles only

---

RPM and User Consent

Unlike v2.x profile download (where the end user initiates the download), RPM is operator-initiated. However, the specification still requires end user consent and confirmation:

• Each RPM Command requires a Confirmation Request enforced by the LPA
• Multiple Confirmation Requests for consecutive commands MAY be combined to simplify UX (e.g., a single confirmation for “Disable Profile A and Enable Profile B”)
• When combined, the highest Confirmation Level applies (Simple → Strong)
• The LPA must make it clear to the End User what RPM Commands will be executed

The end user can reject: in which case the LPA cancels the session and the RPM Package is never executed.

---

RPM and Notifications

After RPM execution, the Operator receives the Load RPM Package Result. Based on the outcome:

• The Operator can initiate additional RPM operations (e.g., if Contact PCMP failed with noLprConfiguration, re-send with UpdateMetadata to set the PCMP address first)
• The SM-DP+ sends ES2+.HandleNotification calls to the Operator for RPM-related events
• If profiles were enabled/disabled/deleted, the LPA handles the corresponding notifications to the SM-DP+ as per local profile management rules

---

Comparison: v2.x Local vs v3.x Remote Management

Aspect	v2.x Local Profile Management	v3.x Remote Profile Management
Initiated by	End User (via LUI)	Operator (via ES2+.RpmOrder)
Discovery	Not needed (user initiates)	MatchingID, SM-DS Event, or Default SM-DP+
Commands available	Enable, Disable, Delete (local)	Enable, Disable, Delete, ListProfileInfo, UpdateMetadata, Contact PCMP
User consent	Acquired locally by LUI	Acquired by LPA during RPM Download
Package format	N/A (individual ES10c calls)	RPM Package (ASN.1 sequence of commands)
Error handling	Per-command, immediate feedback	Per-command with continueOnFailure option
Chaining	Not applicable	rpmPending for multiple packages
Atomicity	Per ES10c call	Per RPM Command within a package

---

Summary

• RPM is a v3.x-only feature enabling operator-initiated remote profile lifecycle management
• Three phases: Initiation (Operator → SM-DP+), Download (LPA pulls from SM-DP+), Execution (eUICC processes)
• Six RPM Commands: Enable, Disable, Delete, ListProfileInfo, UpdateMetadata, Contact PCMP
• Each command requires end user confirmation; confirmations can be combined for UX
• RPM Packages limited to 1057 bytes; rpmPending enables multi-package chaining
• continueOnFailure allows graceful error handling within a package
• A Profile may have multiple Managing SM-DP+s authorised for RPM

---

← Previous: Version Interoperability: How v2.x and v3.x Coexist Next: Device Change and Profile Recovery: Moving eSIMs Between Devices →

---

Based on GSMA SGP.22 v3.1 (01 December 2023), Section 2.10: Remote Profile Management, Section 3.7: Remote Profile Management, and Section 5.3.6: ES2+.RpmOrder

---

← Previous: Version Interoperability: How v2.x and v3.x Coexist

Section Index

Next: Device Change and Profile Recovery: Moving eSIMs Between Devices →