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.41 IFPP > IFPP Security: Factory Trust Models and Certificate Chains
💡 Why this matters: Factory floors are untrusted environments. The Device Manufacturer and FPA handle profile packages but must never see them in plaintext. One-time keys, forward secrecy, and pre-encryption create a security model where the factory is a courier, not a custodian: the profile’s confidentiality and integrity are preserved end-to-end from the SAS-certified SM-DPf to the eUICC, regardless of what happens on the production line.
Key takeaways:
- SGP.41 implements defence in depth for the factory: the Device Manufacturer never has access to clear-text private/secret keys used for binding (GENS10), and clear-text profiles only exist inside the eUICC (GENS09)
- One-time keys are the cryptographic linchpin: randomly generated (GENS07), single-use (GENS08), SAS-UP generated and loaded (GENS14), and tied to a specific eUICC (GENS12)
- Perfect Forward Secrecy (PFS) is required for every profile binding (GENS06) : compromise of the SM-DPf’s long-term key does not expose previously bound profiles
- The SM-DPf’s private key MUST be protected in an SAS-certified HSM (GENS05); the EUM MUST be SAS-accredited (EUMS01); the SM-DPf MUST be SAS-accredited (DPFS01)
- Two explicit security options reduce factory burden: Option 1 allows no SAS accreditation for the Device Manufacturer (GENS01); Option 2 allows no HSM at the Device Manufacturer (GENS02)
- Anti-cloning is built in: a profile can only be loaded to one eUICC (GENS04), enforced by the one-time key binding
- FPA Services are only available during the Device Production Process (GENS13) : they cannot be invoked in the field
SGP.41’s security model starts from a blunt premise: the factory is not trusted with profile secrets. Every security decision flows from this premise. The Device Manufacturer and FPA handle Bound Profile Packages but can never decrypt them. The SM-DPf does all cryptographic operations in a SAS-certified HSM before the profile reaches the factory. The result is a model where even a fully compromised factory cannot extract profile keys or clone profiles.
SM-DPf HSM Factory (untrusted) eUICC
───────── ────────────────── ─────
[Profile] [BPP in transit] [Profile]
│ │ ▲
├─ encrypt to eUICC's ├─ push through FPA │
│ one-time public key │ (cannot decrypt) │
│ │ │
├─ sign with SM-DPf ├─ store temporarily ├─ decrypt with
│ private key │ (cannot decrypt) │ one-time private key
│ │ │
└─ include SM-DPf cert └─ load onto eUICC ├─ verify SM-DPf sig
chain │
└─ verify cert chain
The profile exists in plaintext at exactly two points: inside the SM-DPf’s SAS-certified HSM during generation and binding, and inside the eUICC after decryption and installation. At every point in between: in transit over Esbpp, in storage at the Device Manufacturer, during Esfac transfer, during ES10f forwarding: it is a cryptographically bound and encrypted BPP that no factory entity can read.
One-time keys are the foundation of IFPP security. Here’s how they work:
One-time keys solve several problems simultaneously:
Anti-cloning: A BPP encrypted to eUICC-A’s one-time key cannot be installed on eUICC-B: only eUICC-A has the corresponding private key (GENS04).
Offline binding: The SM-DPf can bind a profile to an eUICC without any real-time communication. It only needs the public key, which it receives in advance.
No long-term correlation: Because each key is used once, an attacker who compromises one BPP learns nothing about other BPPs bound to the same eUICC.
Factory-side simplicity: The Device Manufacturer never touches private keys: it only passes through encrypted BPPs.
IFPP reuses the PKI infrastructure from SGP.21/SGP.31:
Esci interface (out of scope for SGP.41)When the eUICC receives a BPP (step 10 of the IFPP flow), it verifies:
The SM-DPf retrieves certificate revocation status from the eSIM CA via the Esci interface. The eUICC is expected to have mechanisms for certificate validation consistent with SGP.21/SGP.25 requirements: though CRL loading during IFPP itself is not detailed in the v1.0 specification.
SGP.41 explicitly defines two options that reduce the security burden on the manufacturing environment:
“There SHALL be an option where Profile provisioning related security accreditation (e.g., GSMA SAS) is not required for the Device Manufacturer.”
This is a critical design choice. Traditional eSIM profile handling (SM-DP+ operations) requires SAS accreditation. By shifting all security-sensitive operations to the SM-DPf (which MUST be SAS-accredited: DPFS01), SGP.41 lets factories operate without SAS certification. This is explicitly called out in the IoT use case (Annex A.2): “CheapDevice does not want its production facility constrained by strong additional security requirements, e.g., get a SAS certification for its production facility.”
“There SHALL be an option where an HSM at the Device Manufacturer is not required.”
The Device Manufacturer never holds plaintext profile keys or performs cryptographic operations on profile material. An HSM would protect nothing of value. SGP.41 eliminates this cost and complexity.
Two requirements define the absolute security boundaries:
GENS09: “At the Device Manufacturer, the clear-text Profile Package SHALL only exist inside the eUICC.”
The Device Manufacturer handles BPPs (encrypted), stores BPPs (encrypted), transports BPPs (encrypted), and pushes BPPs through the FPA (encrypted). At no point does the Device Manufacturer’s infrastructure see or touch a plaintext profile.
GENS10: “The Device Manufacturer SHALL never have access to the clear-text private/secret keys used for binding of Profile Packages.”
The one-time private keys stay in the eUICC. The SM-DPf’s private key stays in its SAS-certified HSM. The Device Manufacturer may handle public keys and eUICC certificates: but never private key material.
SGP.41 requires that each profile binding incorporate Perfect Forward Secrecy: “Each Profile binding SHALL incorporate Perfect Forward Secrecy (PFS).”
This means:
A subtle but important security control: the FPA Services on the eUICC are only available during the Device Production Process:
“The FPA Services SHALL only be available during the Device Production Process.”
How this is enforced is Device Manufacturer and/or EUM specific (the spec notes this is implementation-dependent). Once the device leaves the factory, the FPA Services are locked: preventing any post-production attempt to use the factory provisioning path for malicious profile loading.
Additionally, the eUICC gates LPA/IPA Services: “The eUICC SHALL only authorise the use of the LPA Services… or the IPA Services… if there is no One-time Key” (EUICCF04). This means while one-time keys remain on the eUICC (indicating the factory phase is still active), the field-side profile management interfaces are blocked: and vice versa.
SGP.41 Annex B identifies four categories of threats:
Based on GSMA SGP.41 v1.0 (28 February 2025) : eSIM In-Factory Profile Provisioning Architecture and Requirements, Sections 4.2 and Annex B
| ← Previous: IFPP Flow: Manufacturing Step to Configuration Step | Section Index | Next: IFPP in Practice: PC OEMs, Automotive, and IoT Manufacturing → |