An eIM that works in a lab with one chip is not the same thing as an eIM that works in your fleet.

The SGP.32 (GSMA specification for IoT eSIM remote provisioning) spec is detailed enough that two implementations can each be technically compliant and still fail to work together. The reason is implementation variance — the parts of the spec where vendors make legitimate but different choices about encoding, session handling, or interface behavior. An eIM (eSIM IoT Manager — the server that orchestrates remote profile management for IoT devices) that has only been tested against a single eUICC (embedded SIM chip) manufacturer carries unknown risk for every other chip family it encounters in the field. That risk doesn’t announce itself. It shows up as a profile download that hangs, a session that times out for no apparent reason, or a rollback that doesn’t complete.

Testing against multiple eUICC manufacturers isn’t a quality bonus. It’s the evidence that the eIM actually works.

What Interoperability Testing Involves

The SGP.32 spec defines the interfaces, the message formats, and the state machine that governs how an eIM and an eUICC communicate during a profile operation. What it doesn’t fully standardize is every implementation decision a chip vendor makes within that framework.

An eUICC manufacturer — or EUM, such as Kigen (ARM), ST Microelectronics, or VALID — implements the eUICC’s firmware, its IPA (IoT Profile Assistant) client, and the behavior of the IPAe interface (the interface between the eIM and the SIM-side IPA). Those implementations are compliant with the spec, but they’re not identical. They differ in:

Encoding choices. SGP.32 permits both ASN.1 and JSON message encoding. An eIM that only generates ASN.1 messages will fail against an eUICC that expects JSON. An eIM that generates both, and handles both in responses, works with either.

Session timing and retry behavior. The spec allows for variation in how quickly an eUICC expects an acknowledgment after initiating a BIP (Bearer Independent Protocol) channel. A tight timeout on one chip may cause session failures on an eIM with slightly delayed responses — not a bug in either system individually, but a gap between them.

Profile download state handling. The sequence of states an eUICC moves through during a profile download — from notification to download to enable — can proceed at different speeds depending on the chip’s internal scheduler. An eIM that assumes uniform state transition timing may send the next command before the eUICC is ready to receive it.

Error reporting format. When something goes wrong mid-operation, different eUICC implementations encode error responses differently within the spec’s allowed range. An eIM that hasn’t been tested against a given chip’s error format may fail to parse the response correctly, causing a silent failure instead of a recoverable error.

Interoperability testing surfaces all of these. It requires running actual profile operations — push, enable, disable, delete, rollback — against each chip family, observing failures, and updating the eIM’s handling until operations complete reliably across all tested variants.

Why Compliance Doesn’t Equal Compatibility

This is the part that surprises buyers who assume GSMA certification is a sufficient guarantee. It isn’t — and not because certification is worthless. It’s because certification tests conformance to the spec, not interoperability with every other implementation of the spec.

The consumer eSIM world (SGP.22) had a long period where certified devices and certified SM-DP+ servers failed to work together in ways that weren’t caught until field deployment. SGP.32 is a newer spec, the implementation surface is larger, and the device ecosystem is significantly more fragmented. The conditions for hidden incompatibilities are better, not worse, than in the consumer case.

The practical implication: an eIM vendor that says “we’re SGP.32 compliant” without being able to name the specific eUICC families they’ve tested against is giving you a necessary but insufficient answer. Compliance tells you they’ve implemented the spec. It doesn’t tell you whether their implementation works with the chip inside your device.

As Simplex’s own SGP.32 implementation journey documents, building a carrier-grade eIM requires supporting multiple communication stacks — both normal and compact — as well as both IPAe and IPAd approaches, because the spec allows variation and the real device ecosystem exercises that variation. An eIM that was built against one chip vendor’s reference implementation and never tested further carries implementation assumptions that may not hold elsewhere.

The Four Variables That Break Untested Implementations

Four specific areas of the SGP.32 spec contain enough implementation latitude that an eIM that hasn’t been tested across chip families is likely to have hidden fragility in at least one of them.

What Simplex Has Tested — and Why It Matters

Simplex has completed interoperability testing with Kigen (ARM), ST Microelectronics, and VALID — three of the major eUICC manufacturers. Each test covered the full profile operation lifecycle across both IPAe and IPAd approaches, both ASN.1 and JSON encoding, and both normal and compact communications stacks.

This testing isn’t a marketing claim. It’s the output of building an eIM from scratch with a team that spent 30 years building carrier-grade platforms for tier-1 mobile operators — systems that process tens of thousands of transactions per second with the fault tolerance and operational maturity that entails. As the SGP.32 lessons learned post details, the spec demands predictable, fault-tolerant communication between the eIM, the eUICC, and the IPA. Building for that kind of reliability is not compatible with single-vendor testing assumptions.

The practical consequence is straightforward: if your device uses a Kigen, ST Micro, or VALID eUICC, Simplex’s eIM has been verified to work with it. Not assumed — verified. For the IPAe turnkey SIM approach, where Simplex ships the eUICC-enabled SIM card alongside eIM access, the whole stack is tested end-to-end before it ships. The BIP/STK enablement requirements for each tested modem are documented publicly, so integration teams aren’t starting from scratch.

Simplex is also not an EUM. That neutrality matters: chip manufacturers benefit from testing against an eIM they don’t control, because it validates their own implementation. Simplex’s independence makes it a useful testing partner, not a competing vendor. That’s how testing relationships with multiple EUMs become possible in the first place.

What to Ask Before You Commit to an eIM Provider

When you’re evaluating eIM vendors, interoperability testing history is one of the most revealing questions you can ask — because it’s one of the hardest to fake. “We’re SGP.32 compliant” is a minimum bar. The better questions are:

Which eUICC manufacturers have you tested against? Can you name them specifically, and confirm that testing covered the full profile lifecycle?

What encoding formats does your eIM support — ASN.1, JSON, or both?

Have you tested both IPAe and IPAd approaches? What modems and chipsets have you validated for each?

What happens when a profile operation fails mid-sequence? Does the device recover automatically, and has that recovery been tested on the eUICC families you support?

Is your eIM built in-house or based on third-party software? If third-party, who owns the testing relationship with EUMs?

Honest answers to these questions tell you whether an eIM vendor has done the work or is relying on spec compliance to carry a conversation they haven’t actually had in hardware.

Where Untested Implementations Fail in the Field

The failure modes aren’t always dramatic. A profile push that works in a lab environment on the vendor’s reference chip may fail intermittently in production on a different chip family, under different network conditions, or after a firmware update on the modem changes the BIP session timing.

The practical consequences range from inconvenient to operationally serious. A failed profile download that recovers cleanly costs a retry. A failed profile download that leaves the device stranded on a profile it can’t use — because rollback wasn’t tested and doesn’t work — costs a truck roll. At fleet scale, that calculus changes fast.

The xoSIM turnkey approach is partly designed around this problem: shipping the eUICC and the eIM from the same vendor means the combination has been tested together before it reaches a customer’s device. That doesn’t mean every possible integration scenario is covered, but it eliminates the most common source of interoperability unknowns.

For teams bringing their own eUICC and evaluating Simplex’s eIM standalone, the Works With Simplex program provides a documented compatibility list of validated modems and chip combinations. If your hardware is on the list, you have a tested baseline. If it isn’t, that’s a test worth running before deployment, not after.

The spec is the floor. Interoperability testing is what separates a platform that works on the spec from one that works in your fleet. If you’re evaluating eIM providers, ask to see the testing receipts — and if they can’t produce them, factor that into your assessment.

Explore Simplex’s eIM platform and see which eUICC families we’ve tested at simplexwireless.com/xosim.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen