SGP.32 eSIM Security: Protecting Your Fleet from Profile Hijacking

The Security Stakes in IoT eSIM

SIM swapping – the fraudulent transfer of a phone number to an attacker-controlled SIM – has been a consumer security problem for years. In 2025 and 2026, the same attack vector has migrated to IoT fleets. An attacker who can push an unauthorised profile to an IoT device can redirect its cellular traffic, intercept its data, or disable its connectivity entirely.

For a utility company managing smart meters, a logistics firm tracking containers, or a healthcare provider monitoring wearables, a compromised fleet is not just a technical problem. It is a regulatory incident and potentially a safety risk.

SGP.32 has strong security built into its architecture. Understanding what is protected by the standard and what still requires your own security posture to address is essential to building a genuinely secure IoT deployment.

How SGP.32 Secures Profile Operations

Mutual Authentication

In SGP.32, every profile lifecycle operation between the eIM and the eUICC requires mutual authentication. This means both parties must prove their identity before any operation proceeds – the eIM proves it is an authorised management server, and the eUICC proves it is a legitimate device. An attacker cannot push a fake profile to a device simply by sending the right API call, because they do not hold the private keys required for the cryptographic handshake.

The authentication chain runs through the GSMA Certificate Issuer infrastructure – a root of trust managed by the GSMA that validates the identity of every eIM and every eUICC in the ecosystem. This means the security guarantee is not provided by any single vendor but by the standards body itself.

Integrity Protection

All profile packages in SGP.32 are cryptographically signed before delivery and verified after receipt. A profile that has been tampered with in transit will fail integrity verification and be rejected by the eUICC. The device cannot be loaded with a malicious profile that has been modified after signing.

Encryption in Transit

Profile data is encrypted end-to-end between the SM-DP+ server and the eUICC. The network operator, the cellular carrier carrying the data, and any intermediate network components cannot read the profile content in transit. This protects the profile from interception during delivery.

Physical Security: Why MFF2 Chips Matter

The physical form factor of the eUICC is a security consideration that is easy to overlook. A plastic SIM card can be removed from a device, placed in a SIM reader, and potentially cloned or interrogated. An MFF2 (Machine Form Factor 2) chip is soldered directly onto the device PCB – it cannot be removed without destroying the circuit board.

For deployed IoT devices in physically accessible locations – outdoor enclosures, vehicle installations, public infrastructure – the physical theft of a removable SIM is a genuine attack vector. MFF2 soldered chips eliminate this attack entirely. When specifying hardware for security-sensitive deployments, MFF2 eUICC form factor should be a baseline requirement.

Zero-Trust Device Identity

SGP.32 uses each eUICC unique EID (eUICC Identifier) as the hardware-bound device identity. No two eUICC chips share an EID, and the EID cannot be changed. This creates a genuine hardware root of identity that is more reliable than any software-based device identifier.

The implication for security architecture is significant: a device can only be managed by an eIM that has been cryptographically associated with its EID. An attacker who gains access to your eIM management console cannot push a profile to a device unless that device EID has been registered in your eIM.

The Risks SGP.32 Does Not Eliminate

SGP.32 secures the profile management channel. It does not secure everything else about your IoT deployment.

Default Credentials

A device with a properly managed eSIM profile that uses default firmware passwords is still vulnerable. SGP.32 profile security does not extend to the device management interface. Every device in your fleet should have unique credentials, and default passwords should be rotated before deployment.

Compromised eIM Credentials

If an attacker gains administrative access to your eIM management platform – through credential theft, phishing, or a weak API key – they can legitimately push profile changes to your fleet. The cryptographic protections of SGP.32 will happily authenticate a legitimate eIM user performing malicious actions. Strong authentication on the eIM management console, including multi-factor authentication, is essential.

Insecure APN Configuration

An operational eSIM profile on a shared APN with dynamic IPs may expose device traffic to other tenants on the same APN. Private APN with fixed IP addressing prevents this and should be standard for any security-sensitive deployment.

What to Ask Your Provider About Security

• Is your eIM environment GSMA SAS-SM accredited? (This is the baseline security certification for eSIM management infrastructure)
• Do you support private APN with fixed IP allocation on SGP.32 operational profiles?
• What multi-factor authentication options are available for eIM console access?
• How are eIM API keys issued, rotated, and revoked?
• What audit logging is available for profile operations – can you show me every action taken on a specific device?
• What is your incident response process if a compromised eIM credential is identified?

For guidance on the broader SGP.32 architecture that underpins these security features, see the Architecture Guide. For questions to ask your provider about their security posture, see What to Ask Your eSIM Provider.