A GSMA count finds five of eight eIM implementations pin an SGP.32 fleet to one manager

The procurement line for connected devices usually reads "SGP.32 compliant", and buyers read that as protection against lock-in. What the line states is compatibility: the device can be provisioned over the air today, and it says nothing about who controls the provisioning event in year eight ^[13].

The mechanism sits in a component most buyers never negotiate: the eSIM IoT Remote Manager, or eIM. SGP.32 allows a device to switch among multiple eIMs, and some implementations simply do not support that ^[3]. Five of the eight publicly available implementations support only a non-configurable model, according to a GSMA market report cited in a DataCenterDynamics opinion piece ^[4][17]. Subtract and three are left, so about 38 percent of what a buyer can shop for today keeps the door open ^[15].

Buying the standard moves the dependency one layer up. In the non-configurable model you can still change connectivity providers, as long as the new provider sits inside the ecosystem your original eIM supports ^[5]. The eIM becomes the gatekeeper to every connectivity decision after the first one, and a customer who cannot change it may never reach new provider ecosystems that appear later ^[6].

The service life is what makes this expensive. These devices are expected to stay in service 10 to 15 years ^[9]. Across that window 2G and 3G are retired, 4G eventually goes, and operator strategies on NB-IoT and LTE-M move ^[10]. DCD's example is a company that builds for North America or Europe and later wants Brazil, Indonesia or Africa; if the connectivity architecture cannot adapt to local coverage and regulatory requirements, that expansion becomes expensive or commercially unviable ^[11].

Devices still work. The risk DCD names is that a fleet cannot function reliably or stay commercially viable in a new market ^[16], and the piece is explicit that these implementations are fully permissible within the current standard ^[7]. Because non-configurable is compliant, certification never surfaces the question.

The forcing function is two questions, asked separately, and scored separately. First, whether the vendor can add a connectivity provider it has no existing relationship with. Second, whether the eIM itself can be replaced on a device already installed in the field, and by what procedure. A vendor that answers the first and talks around the second is selling compatibility, which is the distinction the DCD piece draws against interoperability ^[13]. What the evidence supports is a count of implementations, not a documented failure in a live fleet; DCD describes the operational case as the first of two types of lock-in it identifies, the other being cryptographic ^[8]. The report behind the count is free to download with no sign-up ^[14], which makes it cheap to check a vendor's answer against.