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 v3.x Unified RSP > Policy Management in SGP.22 v3.x: PPR, RAT, and the Policy Enforcer
💡 Why this matters: Without policy management, any profile on your eSIM could be disabled or deleted by anyone: the end user, a malicious app, even a different operator. Profile Policy Management gives Profile Owners (operators) the ability to enforce conditions of use: a corporate-issued profile that can’t be deleted by the employee, or a subsidised-device profile that can’t be disabled until the contract ends. The system is carefully balanced: the eUICC manufacturer sets the ground rules (RAT), the operator sets per-profile policies (PPRs), and the eUICC enforces them (PPE). v3.x extends this with MEP-aware enforcement and lays groundwork for Enterprise Rules.
Key takeaways:
- Three components: Profile Policy Rules (PPRs) set by operators, Rules Authorisation Table (RAT) set by the manufacturer, and Profile Policy Enabler (PPE) on the eUICC
- Two PPRs defined: PPR1 : “Disabling of this Profile is not allowed”, PPR2 : “Deletion of this Profile is not allowed”
- The RAT defines which operators can use which PPRs, and whether end user consent is required: using MCC/MNC wildcards for flexible operator matching
- Both the LPA (during download) and the eUICC (during installation and operation) independently verify PPRs against the RAT: a dual-layer enforcement model
- MEP changes everything for PPR1: On MEP-capable eUICCs, PPR1 is simply not enforceable: the RAT SHALL NOT contain PPAR entries for PPR1
- The RAT survives eUICC Memory Reset: it’s a platform-level configuration set at manufacturing or initial device setup
- v3.x introduces Enterprise Rules as a separate policy layer, enforced by the Profile Rules Enforcer alongside PPRs
Profile Policy Management (section 2.9) rests on three components working together:
PPRs are the operator’s expression of intent. They’re set by the SM-DP+ in the Profile Metadata and travel with the profile throughout its lifecycle. Two rules are defined in v3.1 (section 2.9.1):
A Profile may have zero, one, or both PPRs set. Test Profiles should not contain PPRs. PPRs may only be provided for profiles containing an EF IMSI (i.e., operational profiles).
PPRs are encoded as a bit string in the Profile Metadata:
PprIds ::= BIT STRING {
pprUpdateControl(0), -- controls PPR update mechanism via ES6
ppr1(1), -- 'Disabling of this Profile is not allowed'
ppr2(2) -- 'Deletion of this Profile is not allowed'
}
A bit set to '1' indicates the corresponding PPR is active.
The RAT is the gatekeeper. It’s defined at the eUICC platform level and determines which operators are allowed to use which PPRs, and under what conditions (section 2.9.2).
The RAT contains a list of Profile Policy Authorisation Rules (PPARs), each specifying:
| Field | Description |
|---|---|
| PPR Identifier | Which PPR(s) this rule applies to (PPR1, PPR2, or both) |
| Allowed Operators | Which operators (by MCC/MNC + optional GID1/GID2) can use this PPR. Wildcards supported. |
| End User Consent Required | Whether the LPA must obtain explicit end user consent before installing a profile with this PPR (true/false) |
The RAT is initialised at eUICC manufacturing time or during initial device setup (before any operational profile is installed). The Device manufacturer or EUM is responsible for its content. Critically, the RAT survives ES10c.eUICCMemoryReset : it’s a permanent platform policy.
Wildcard matching is flexible:
'E' (e.g., 'EEEEEE' matches all operators)PPAR ordering matters: When a Profile Owner matches multiple PPARs for the same PPR, the first matching PPAR determines whether end user consent is required.
Example RAT configuration:
| PPR | Allowed Operators | End User Consent |
|---|---|---|
| PPR1 | OP-A | false |
| PPR2 | OP-B | false |
| PPR1, PPR2 | * (all operators) | true |
With this configuration:
Notable preset configurations (section 2.9.2.2):
The PPE lives on the eUICC and has two jobs (section 2.9.3):
One of the most important design features of SGP.22 policy management is that both the LPA and the eUICC independently verify PPRs. This provides defence in depth:
During the Profile Download and Installation procedure (section 3.1.3, step 7), the LPA retrieves the RAT via ES10b.GetRAT and the list of installed profiles via ES10c.GetProfilesInfo. It then checks:
pprNotAllowedpprNotAllowedThe LPA also verifies PPRs a second time after BPP download (step 12) : checking that the metadata in the bound package hasn’t changed from what was received earlier.
During ES8+.StoreMetadata processing (section 3.1.3.3, step 4a), the PPE on the eUICC performs its own independent PPR verification:
This dual-layer approach means that even if a compromised LPA tried to install a profile with unauthorised PPRs, the eUICC’s PPE would reject it independently.
A PPR can be unset after installation via ES6.UpdateMetadata (by the Profile Owner) or via the RPM UpdateMetadata command. Setting a PPR after installation is “for further study” : the spec currently only defines removal, not addition.
Multiple Enabled Profiles (MEP) creates an inherent conflict with PPR1. If PPR1 means “this profile cannot be disabled”, what happens when the user wants to enable a different profile but the eUICC supports multiple enabled profiles?
The specification resolves this cleanly (section 2.9.2.1):
The RAT of an eUICC supporting MEP SHALL NOT contain any PPAR for PPR1.
In other words, PPR1 is incompatible with MEP. On a MEP-capable eUICC, no operator can set PPR1: profiles with PPR1 set will be rejected during installation by both the LPA and the eUICC. This makes sense: with MEP, enabling a new profile doesn’t require disabling the current one, so the “disabling not allowed” restriction loses its meaning.
This also means that device manufacturers choosing to support MEP must accept that PPR1-based business models (e.g., permanently locked subsidised-device profiles) won’t work on their platform. Operators who rely on PPR1 must target SEP-only devices.
When the end user (or the LPA on their behalf) attempts a local profile management operation, the PPE checks the relevant PPRs (section 2.9.3.3):
Exception: Test Profiles (section 2.9.3.3.2): When a Test Profile needs to be enabled while the currently enabled profile has PPR1 set, the PPE does not enforce PPR1. This allows device testing without being locked out by production profiles. The eUICC implicitly disables the operational profile to enable the test profile, and re-enables the operational profile when the test profile is disabled: maintaining the spirit of PPR1 while permitting test operations.
Exception: Provisioning Profiles: The LPA can enable a Provisioning Profile even when the currently enabled operational profile has PPR1 set. The eUICC implicitly disables the operational profile for the duration of provisioning.
v3.x extends the policy framework in two important ways:
The Profile Rules Enforcer (section 2.4.12) now enforces not just PPRs but also Enterprise Rules : a separate policy layer for enterprise-owned devices. Enterprise Rules can:
onlyEnterpriseProfilesCanBeInstalled)priorityEnterpriseProfile)numberOfNonEnterpriseProfiles)Enterprise Rules are enforced by the eUICC independently of PPRs, creating a multi-layer policy stack.
Remote Profile Management (RPM) commands must respect PPRs: an RPM Disable command targeting a profile with PPR1 set will be rejected, and an RPM Delete targeting a PPR2 profile will be rejected. RPM Commands targeting Test Profiles are always rejected: RPM is for Operational Profiles only.
Based on GSMA SGP.22 v3.1 (01 December 2023), Section 2.9: Profile Policy Management, and related sections on Profile Rules Enforcer (2.4.12) and Enterprise Configuration (2.4a.1.7)
| ← Previous: Profile Protection & BPP Security: How eSIM Profiles Stay Secret | Section Index | Next: Enterprise Profiles in SGP.22 v3.x: Corporate Control of eSIMs → |