What is an eIM? The eSIM IoT remote Manager explained

An eIM (eSIM IoT remote Manager) is the server in the GSMA SGP.32 architecture that manages eSIM profiles on fleets of IoT devices. It tells each device which operator profile to download from an SM-DP+, and it sends signed commands to enable, disable or delete profiles on the device’s eUICC. The eIM takes the place of the user in consumer eSIM and of the operator-run SM-SR in M2M eSIM, and it never sees the contents of the profiles it manages.

This page explains what an eIM does, how it differs from an SM-SR, how its packages and security model work, and what to check when you choose or test one.

What an eIM does

An eIM is defined by SGP.31 (requirements) and SGP.32 (technical specification). Its job is to orchestrate, not to store profiles. In practice an eIM:

• Triggers profile downloads. It passes an activation code, an SM-DS event, or an instruction to use the default SM-DP+ to the device’s IoT Profile Assistant (IPA).
• Proxies downloads when needed. In “indirect” download the eIM talks to the SM-DP+ on the device’s behalf over ES9+’, which helps devices that cannot open their own TLS session to an arbitrary server.
• Manages profile state. It sends signed Profile State Management Operations (PSMOs) such as enable, disable and delete.
• Manages its own association. It can add, update, delete or list the eIMs associated with an eUICC.
• Collects results and status. It receives signed execution results, download notifications, and data such as the EID, installed profiles and IPA capabilities.
• Queues work per device. Packages wait in a queue keyed by EID until the device next connects, which matters for devices that sleep for hours or days.

Everything else, such as fleet dashboards, APIs, operator selection rules or integration with billing, is product functionality layered on top. The standard defines the interfaces, not the user experience.

eIM vs SM-SR

The eIM is often described as “the SGP.32 replacement for the SM-SR”, but the two work very differently.

	SM-SR (SGP.02)	eIM (SGP.32)
Typically operated by	An operator, or a platform on its behalf	Device owner, enterprise, MVNO, connectivity provider or eUICC vendor
What it holds	Secure channel keys to the eUICC’s root security domain	A signing key; the eUICC stores only the eIM’s public key or certificate
How commands are protected	Secure channel between SM-SR and eUICC	ECDSA-signed eUICC Packages, replay counter, eUICC-signed results
Transport to device	SMS, CAT_TP, SMS-triggered HTTPS	HTTPS, CoAP/DTLS, or the device’s own protocol (LwM2M, MQTT)
Where profiles come from	SM-DP linked to the SM-SR	Any operator’s SGP.22-style SM-DP+
Changing operator	Often requires moving the eUICC to another SM-SR	Hand the eIM a new activation code
Changing the manager	“SM-SR change” between two platform operators	Signed add/delete eIM operations

The practical consequence is control. With an SM-SR, the operator’s platform holds the keys. With an eIM, the party that owns the devices can keep the same management system while changing operators.

eIM Packages and eUICC Packages

Two package concepts appear throughout SGP.32, and they are easy to confuse.

eIM Packages: what travels to the IPA

An eIM Package is whatever the eIM sends to the IPA over the ESipa interface. SGP.32 v1.2 (section 2.11) defines four kinds:

eIM Package	Contains	Used for
eUICC Package request	A signed eUICC Package (see below)	Changing profile state or eIM configuration
IPA/eUICC data request	A list of data items wanted	Reading EID, profile list, notifications, IPA capabilities, eUICC info
Profile download trigger	Activation code, SM-DS event or “use default SM-DP+”	Starting a download
Acknowledgements	Sequence numbers	Confirming receipt of results and notifications

eUICC Packages: what the eUICC verifies and executes

An eUICC Package is the signed part that the IPA hands to the eUICC without being able to alter it. It contains the eIM’s identifier, the target EID, a counter value, an optional transaction ID, and either a list of PSMOs or a list of eIM Configuration Operations (eCOs):

• PSMOs: enable (optionally granting rollback), disable, delete, list profile info, get the Rules Authorisation Table, configure immediate enable, set or unset the fallback attribute, set the default SM-DP+ address.
• eCOs: add eIM, update eIM, delete eIM, list eIMs.

The eUICC verifies the signature, checks that the counter is higher than the last one it accepted from that eIM, executes the operations, and produces an eUICC Package Result signed with its own key. The IPA returns that result to the eIM, which verifies the eUICC’s signature before updating its records.

eIM association and selection

An eUICC only obeys eIMs it is associated with. For each Associated eIM it stores eIM Configuration Data, which includes:

• an eIM identifier and its type (OID, FQDN or proprietary), plus an address, which may be an intermediate server such as an MQTT broker;
• the eIM’s public key or certificate for checking signatures;
• the current counter value and an optional association token for replay protection;
• optional TLS trust data, the transport protocols the eIM supports, and whether it supports indirect download.

The first association happens either at eUICC production or later through the IPA’s AddInitialEim function, which is accepted only while no eIM is associated. From then on, every change must be a signed eCO from an already associated eIM. Replacing a provider therefore means the current eIM adds the new one and then the old one is deleted. If the last eIM is deleted, the eUICC accepts an initial association again. An eUICC can hold more than one Associated eIM, each with its own counter.

Selection is therefore a long-term decision. Before choosing an eIM, check how the association will be created in your manufacturing flow, and confirm in writing how a future migration to another eIM would be carried out.

Transport and interoperability

SGP.32 is deliberately flexible about how eIM Packages reach the device, and that flexibility is the main interoperability risk.

• Retrieval or injection. The IPA can poll the eIM (“eIM Package Retrieval”) or the eIM can push to the IPA (“eIM Package Injection”). Each side needs at least one; both must use the same one. The specification recommends that an eIM serving many device types support both. How a sleeping device is told to poll is out of scope.
• Secure connection. HTTPS over TCP (TLS 1.2 minimum, server authentication) is recommended wherever TCP works. CoAP over UDP with DTLS (1.2 minimum) suits network-constrained devices. Alternatively, ESipa messages can be carried by a protocol the device already uses; the specification includes informative mappings for LwM2M (object 3443 in the OMA LwM2M registry) and MQTT. In that mode, compatibility is the integrator’s responsibility.
• Encodings. ESipa over HTTP can use ASN.1 or JSON bindings.
• Download split. The IPA declares whether it supports direct download, indirect download, eIM-handled activation codes and compact data objects that minimise bytes on the air.

Feature	Why it causes interoperability gaps
Retrieval vs injection	eIM and IPA must support the same mode
HTTPS vs CoAP/DTLS vs proprietary	A CoAP-only IPA cannot talk to an HTTPS-only eIM
Direct vs indirect download	Constrained devices may depend on indirect download
Fallback mechanism	Optional on the eUICC; an eIM may assume it exists
JSON vs ASN.1 binding	Both ends must agree
Wake-up / trigger method	Not standardised; differs per platform

Security model

The eIM’s security rests on a few well-defined mechanisms:

• Signed commands. eUICC Packages are signed with ECDSA on NIST P-256 or brainpoolP256r1. The eUICC holds the matching public key or certificate in its eIM Configuration Data. Issuing and revoking eIM signing certificates is left to implementations.
• Replay protection. Each eIM increments its counter for every package to a given eUICC; the eUICC rejects anything not higher than the last accepted value and must support counters up to at least 8,388,607. An optional association token protects against replaying an entire association sequence after a reset.
• Signed results. The eUICC signs its results, so the eIM can trust that a profile really was enabled or deleted.
• Transport security. The IPA authenticates the eIM through TLS or DTLS. NIST P-256 support is mandatory, and specific AES-GCM cipher suites are required.
• No access to profiles. Profiles are encrypted end to end between the SM-DP+ and the eUICC (interface ES8+), so the eIM never handles profile secrets in clear.

At the operational level, the GSMA’s certification applicability annex lists the eIM, with the SM-DP+ and SM-DS, under the Security Accreditation Scheme for subscription management roles. Functional compliance is tested against SGP.33-3, the eIM test specification. Whoever controls the eIM’s signing key controls your fleet’s connectivity, so key custody (for example in an HSM) deserves as much scrutiny as uptime.

Cloud eIM vs self-hosted eIM

	Cloud (hosted) eIM	Self-hosted eIM
Time to deploy	Fast; provider runs and updates it	Slower; you build or license and operate it
Signing key custody	Provider	You
Security accreditation	Provider’s responsibility	Yours
Integration	Provider APIs	Direct integration with your device management
Operator neutrality	Depends on the provider’s commercial model	Full control
Exit path	Needs provider cooperation for signed eCOs	Under your control
Best fit	Most OEMs and enterprises	Very large fleets, regulated sectors, platform providers

What to verify when choosing or testing an eIM

Area	What to verify
Specification version	Which SGP.32 version it implements and whether it has GSMA compliance evidence
Transport	Retrieval and/or injection; HTTPS, CoAP/DTLS, LwM2M or MQTT, matching your IPA
Download modes	Direct and indirect download; activation code, SM-DS and default SM-DP+ triggers
Operations	Every PSMO and eCO you plan to use, including rollback and fallback
eUICC compatibility	Tested with your eUICC vendor and your IPAd or IPAe
Sleeping devices	Queue depth, package expiry, behaviour with PSM and eDRX
Results	Signed results verified, notifications forwarded to the SM-DP+, clear error reporting
Migration	Documented, tested process for adding another eIM and deleting the current one
Security	Key custody, accreditation, access control on the eIM’s own API
Operations	SLA, monitoring, audit logs, regional hosting

What this means for testing

An eIM can pass every conformance test and still fail in the field: a package waits forever for a device that never polls, an enable succeeds but the new profile cannot attach, or a rollback is never granted. The only reliable proof is to drive real devices through the eIM on live networks and check the result at every step, from package delivery to network registration and data. The SGP.32 testing guide covers that sequence in detail.

SimCheck.ai uses a cloud eIM to install SGP.32 profiles onto real modems and then verifies attach, data and MQTT connectivity on the new profile. See SGP.32 IoT eSIM testing for how teams use it to validate eIM, eUICC and operator combinations before rollout.