CSL buys IoTM Solutions to build a multi-carrier control layer for SGP.32 IoT
The deal folds a vendor-agnostic SIM and eSIM management plane into CSL’s managed connectivity portfolio, pitching a single policy-driven layer above fragmented operator and CMP platforms just as SGP.32 starts to reshape how large IoT fleets are provisioned.
What has been announced
CSL Group has agreed to acquire IoTM Solutions, a cloud-native connectivity management vendor whose platform unifies SIM and eSIM operations across multiple carriers. Financial terms have not been disclosed.
IoTM says its platform already manages more than 30 million SIMs, with headroom it claims can scale past a billion, and ships native integrations into over 20 CMP, API and carrier systems covering more than 100 mobile network operators. That estate will be absorbed into CSL’s managed connectivity portfolio, including its patented rSIM resilience service, while existing customer and operator contracts continue running on the current platform.
CSL itself already manages more than three million connections across building security, healthcare, infrastructure, utilities and transport. The company is framing the acquisition as a way to convert scattered, multi-carrier estates into one service that can be governed by policy rather than by juggling operator portals.
What IoTM actually adds
IoTM Solutions launched in 2015 with a narrow goal: take the pain out of running IoT connectivity across several operators, platforms and countries at once. Its answer was a management plane that sits on top of heterogeneous carrier back ends and presents them as a single environment.
In practice that means SIM lifecycle operations, eSIM profile management, usage reporting, support workflows and API access all live in one place. Instead of a separate portal per operator, a customer gets one operating layer for provisioning, state changes, quota enforcement and diagnostics. IoTM reports that large fleets can be provisioned in hours rather than days, and that adding a new carrier is handled through pre-built adapters, turning what is usually a bespoke integration project into a configuration task.
Dan Amir, IoTM’s CEO and co-founder, frames the move as extending these capabilities to a larger global customer base, now backed by CSL’s managed connectivity services and rSIM resilience. The combined pitch is aimed at both enterprises and mobile operators that want to simplify SIM and eSIM operations ahead of the next wave of global IoT.
The real problem: fragmented global estates
Any organisation running a global IoT fleet knows the shape of this problem. You end up straddling multiple CMP generations, several distinct eSIM ecosystems and a spread of carrier-specific portals, each with its own authentication model, reporting format, support channel and billing feed.
Permanent roaming restrictions make it worse. In some jurisdictions you are forced to swap profiles or insert a local operator, which often means opening parallel tickets across several operator systems just to bring devices back online. A single unified plane absorbs those back ends, so a device can roam until the regulations change and then move to a new local profile without re-imaging the remote module or touching application logic.
Paired with rSIM, which handles radio-level failover at the SIM itself, the two mechanisms cover different failure modes. rSIM keeps a data path alive when a radio network drops; the management plane orchestrates profiles at the administrative layer. Blending path resilience with higher-layer profile orchestration is what shortens the windows where a device is genuinely unreachable. It is a different lever from hardware-level approaches like dual-IMSI and dual-modem routers, and in practice the two are complementary.
Worth reading past the marketing. The announcement is candid about integration friction: inconsistent IMSI records, differing carrier API rate limits and error semantics, and usage telemetry that does not line up across operators. Any live cut-over needs reconciliation rules, buffering strategies and tested fallback behaviour before fleets move onto the unified platform.
Why SGP.32 is the real driver
The GSMA’s SGP.32 specification sits behind this deal. It simplifies remote eSIM provisioning for IoT and is built for large device populations and automated lifecycle events, rather than the consumer and M2M models that came before it. Enterprises moving off legacy eSIM standards, or off purely physical SIM architectures, run into profile calendar synchronisation, bootstrap profile changes, subscription management orchestration and the awkward logistics of devices that cannot receive updates over the air.
The CSL and IoTM stack is being positioned as an operational layer above the raw SGP.32 interfaces. The customer defines device inventory, policy rules and commercial constraints, and the platform handles profile staging, downloads, state checks and exception handling across operators. Two useful side effects fall out of that: less lock-in to any single carrier’s SGP.32 implementation, and a clean separation between radio resilience and administrative resilience, so a profile-management outage does not automatically kill data paths, and a radio failure does not strand the management channel.
Ed Heale, CSL Group’s CEO, argues that SGP.32 is the biggest shift in IoT connectivity management since eSIM itself, and that buyers will need a new operating model rather than just a new standard. Bringing IoTM in-house is how CSL intends to deliver that model as a single managed service spanning connectivity management, eSIM orchestration and resilient connectivity.
What IoT buyers should check before believing the numbers
The scale metrics are eye-catching: 30 million active SIMs, billion-SIM capacity and three million existing CSL connections. The announcement also admits there is no independent verification yet of concurrent loads, profile-change rates or how the combined platform behaves under multi-operator failure in the real world.
That is the right prompt for anyone evaluating it. Run your own scenarios against live fleets, not idealised single-operator tests: provisioning during partial network blackouts, regulatory-driven profile exchanges, and spikes in support-query volume all deserve their own dry runs.
| Evaluation area | What to test before you migrate |
|---|---|
| Certification and compliance | Confirm existing certification statuses survive the move to a unified platform, particularly in regulated sectors. |
| SLA behaviour | Validate latency, throughput and support-response SLAs under mixed-carrier traffic, not single-operator benchmarks. |
| Data integrity | Inventory clean-up and dual-write validation phases to catch IMSI and telemetry mismatches early. |
| Rollback | Tested rollback procedures for failed profile installations before touching live devices. |
| Parallel running | Keep legacy CMP tools live alongside the new platform until full consolidation is proven. |
None of this is a reason to avoid consolidation. It is the difference between a migration that quietly works and one that strands remote devices you cannot easily reach.
Based on reporting of the CSL Group acquisition of IoTM Solutions. Scale figures are vendor-stated and, per the original announcement, not yet independently verified.