eSIM and Remote SIM Provisioning Security Guide: Stopping eSIM Swaps and Securing IoT Profiles

With an eSIM, a criminal no longer needs to collect a plastic card from a shop to take over a phone number: a successful social engineering call or a hijacked carrier account can download the victim's profile onto the attacker's device in minutes. Remote SIM Provisioning (RSP) moves the SIM swap from the counter to the network, and the same machinery now provisions millions of connected IoT devices. This guide explains how the GSMA RSP architecture works, where identity and authorisation decisions are made, which roles and integrations carry the most risk, and what carriers, enterprises running mobile fleets and IoT operators should log and harden. It is written for fraud, identity and mobile security teams. It builds on the SIM Swap Fraud Guide rather than repeating it.

Key takeaways

• The weak point is the authorisation to issue a profile, not the cryptography. GSMA RSP protects the profile in transit to a certified eUICC; fraud happens when the carrier issues an activation code to the wrong person.
• Treat every eSIM transfer as a SIM change. US rules define a SIM as "a physical or virtual card associated with a device", so eSIM changes fall within the FCC's SIM change authentication rules (check their compliance status, see below).
• Activation codes and QR codes are bearer credentials. Anyone who holds an unused code can try to download the profile; bind codes to an EID and require a confirmation code where you can.
• SMS one-time codes inherit the risk. NIST SP 800-63B treats PSTN out-of-band authentication as restricted and tells verifiers to consider SIM change and number porting signals; move high-value accounts to phishing-resistant methods.
• IoT RSP adds machine identities at scale. SGP.31 and SGP.32 introduce remote profile management for constrained devices, so the credentials of the platforms that manage those profiles become privileged non-human identities.

How identity and access work in remote SIM provisioning

An eSIM is an embedded UICC (eUICC) that can hold several operator profiles. The GSMA publishes the specifications in families: SGP.21 (architecture) and SGP.22 (technical) for consumer devices, SGP.31 and SGP.32 for IoT devices, and SGP.23, SGP.24 and SGP.33 for testing and compliance. At the time of writing the GSMA lists SGP.22 V3.1 (dated 1 December 2023) among active versions alongside several V2.x versions, and SGP.32 V1.2 and V1.3 as active for IoT. Version status changes: check the GSMA eSIM specification page before relying on a version.

The consumer download flow and where trust is decided

1. Customer requests an eSIM (new line, new device or transfer) through an app, website, call centre or shop.
2. Carrier authenticates the customer and authorises the change. This is the decision that SIM swap fraud targets.
3. Carrier orders a profile from its SM-DP+ and receives an activation code, optionally bound to the target device's EID and optionally protected by a confirmation code.
4. The activation code reaches the device as a QR code, deep link, carrier app hand-off or SM-DS discovery.
5. The LPA and eUICC mutually authenticate with the SM-DP+ and download the bound profile package; the old profile on the victim device stops working on the network.

Steps 2 to 4 are business processes; step 5 is protocol. Everything that makes eSIM fraud possible happens before the cryptography starts. Android's eSIM documentation reflects this: the LPA should not accept an activation code from a result intent, so that non-LPA apps cannot extract codes from the carrier app, and the system API for eUICC operations (EuiccCardManager, which exposes the ES10 functions) is restricted to the LPA.

Admin roles and privileged access

In carriers, the privileged identities for eSIM are the people and systems that can authorise a profile for a phone number. Most real-world eSIM swaps rely on a staff account, a retail partner login or a customer account takeover rather than any attack on the eUICC. See the Telecoms Identity Security Guide.

US regulatory baseline: 47 CFR 64.2010(h) will require wireless providers (the eCFR text says compliance with paragraph (h) is not required until a compliance date is added) to use secure methods reasonably designed to confirm identity before executing a SIM change, to review those methods at least annually, and to train employees to spot fraudulent SIM change attempts and route likely victims to trained staff. 47 CFR 52.37 sets matching authentication and training duties for port-out requests. The FCC's November 2023 Report and Order (FCC 23-95, WC Docket No. 21-341, published in the Federal Register in December 2023) also adopted immediate customer notification of SIM change and port-out requests, a free account lock option and three-year recordkeeping, but compliance waits on OMB review of the information collection requirements, and the codified text showed no compliance date when this guide was checked. Confirm current status on the eCFR and the FCC before quoting obligations. See the FCC CPNI and Telecom Data Breach Rule Guide.

Integrations, API tokens and service accounts

RSP depends on machine-to-machine interfaces, and each one is a non-human identity that can order or move profiles.

• Operator to SM-DP+ ordering interface (ES2+): the business support system calls the SM-DP+ to reserve and release profiles. Protect it with mutual TLS, a dedicated service identity per calling system, IP allow lists and rate limits per hour. A stolen credential here can generate activation codes in bulk.
• Device to SM-DP+ (ES9+) and LPA to eUICC (ES10): standardised and certificate-based. Your job is to keep the PKI current, monitor certificate expiry and follow GSMA certificate policy (SGP.14).
• Carrier app activation APIs: on Android the carrier provisioning service must be protected by WRITE_EMBEDDED_SUBSCRIPTIONS so only the LPA can reach it, and carrier privileges depend on matching certificate hashes in the profile's access rules; Google strongly recommends also checking the package name.
• Self-service web and app transfers: device-to-device transfer features are convenient and are also the attacker's preferred path after an account takeover. Require step-up authentication that does not rely on the phone number being moved.
• Fraud and identity signals: banks and other relying parties increasingly query carrier signals (recent SIM change, port-out) through network APIs. Treat those API keys as sensitive credentials and log every query. See the API Key Management Guide.
• IoT remote management platforms: SGP.32 targets devices with constrained networks or user interfaces, which means no human approves each download. The platform credentials that issue profile changes need rotation, scoping per fleet and alerting on volume.

Logging and detection

eSIM fraud is fast: once the attacker's device has the profile, SMS codes and voice calls go to them. Detection has to work on the change itself and on what follows.

In MITRE ATT&CK the behaviour is T1451 SIM Card Swap (mobile matrix), used to intercept one-time codes (T1111 Multi-Factor Authentication Interception).

Metrics:

• Fraudulent change rate: confirmed fraudulent SIM and eSIM changes per 10,000 changes, by channel.
• EID binding coverage: percentage of activation codes bound to an EID or protected by a confirmation code.
• Time to remediate: median time from victim report to number restored (the FCC record set includes average remediation time).
• Lock adoption: percentage of high-risk customers with an account lock enabled.
• SMS dependency: for relying parties, percentage of privileged or high-value accounts still using SMS as a factor or recovery route.

Hardening baseline

For carriers and MVNOs

1. Authenticate before authorising: in-app push or passkey authentication on the existing device, or strong in-person identity proofing; no knowledge questions.
2. Bind and protect activation codes: bind to the target EID where the flow allows, add a confirmation code delivered out of band, and expire unused codes quickly.
3. Notify on the old device and by email before the change completes, and offer a free lock that blocks SIM changes and port-outs.
4. Apply delay for risky changes: the FCC's 2023 order permits providers to add a delay where needed to prevent fraud; use it when risk signals stack up.
5. Limit staff and dealer power: per-user quotas, dual control for VIP and recently changed accounts, monitoring for insiders.
6. Pilot and roll back: introduce new authentication steps in one channel first, measure abandonment and fraud, and keep the previous flow available as a documented fallback for accessibility needs.

For enterprises and relying parties

• Remove SMS from privileged access: NIST SP 800-63B classes PSTN out-of-band authentication as restricted, says it is not phishing-resistant, and says verifiers should consider risk indicators such as device swap, SIM change and number porting. Use passkeys or hardware keys. See the Passwordless and Passkeys Guide.
• Lock corporate lines: enable carrier account locks and port-out PINs on executive and administrator numbers.
• Control carrier portal access: SSO, MFA and approval for ordering or moving corporate eSIMs.
• Prepare a recovery path that does not depend on the phone number, so a hijacked line does not also mean a locked-out administrator.

For IoT operators

• Treat profile management credentials as privileged NHIs: store them in a secrets manager, scope them per fleet and rotate them.
• Require certified components: eUICCs and SM-DP+ services that meet GSMA certification and security accreditation, and test against SGP.33 where you build your own components.
• Plan for operator change: profile switching is the point of IoT RSP, so define who may approve a fleet-wide switch and how you roll back if connectivity is lost.

Common misconfigurations

• Treating eSIM transfer as a device upgrade, not a SIM change: lighter checks for "move my number to my new phone" flows than for SIM replacement.
• Unbound, long-lived activation codes: QR codes sent by email that remain valid for days and work on any device.
• Knowledge-based authentication in care: date of birth, address or last payment amount, which the FCC's SIM change rules bar relying on once in force.
• Shared dealer logins: no attribution when a store account issues fraudulent changes.
• SMS recovery on administrator accounts: a hijacked number becomes a reset of the email or identity provider account.
• Over-broad IoT platform keys: one API key able to change profiles on every device in every fleet.

Framework mapping

Practitioner checklist

• Map every channel that can authorise a SIM or eSIM change, including dealer and self-service transfer flows.
• Remove knowledge-based checks and require strong authentication on the existing device or in person.
• Bind activation codes to an EID, add confirmation codes and short expiry.
• Notify customers before a change completes and offer a free lock on SIM changes and port-outs.
• Give staff and dealer accounts MFA, quotas and attributable logins, with dual control for high-risk accounts.
• Protect ES2+ and carrier activation APIs with mutual TLS, per-system identities and rate limits.
• Correlate SIM change, port-out and relying party login events and alert on the combination.
• Move privileged and high-value accounts off SMS one-time codes and SMS recovery.
• Scope, vault and rotate IoT profile management credentials; require approval for bulk switches.
• Recheck GSMA specification versions and FCC compliance dates at least yearly.

Standards and references

• GSMA: eSIM specifications
• GSMA: SGP.22 RSP Technical Specification V3.1
• GSMA: SGP.32 eSIM IoT Technical Specification
• eCFR: 47 CFR 64.2010 Safeguards on the disclosure of CPNI (SIM changes)
• Federal Register: Protecting Consumers From SIM Swap and Port-Out Fraud
• NIST: SP 800-63B Authentication and Authenticator Management
• Android: Implement eSIM
• MITRE ATT&CK: SIM Card Swap

Related NHI Mgmt Group resources: SIM Swap Fraud Guide · Telecoms Identity Security Guide · Telecom Network Security Guide · Passwordless and Passkeys Guide