ST’s SoftSIM and SGP.32 Aim to Remove a Factory Choice from IoT Fleets

A water meter, streetlight controller or asset tracker may be built months before anyone knows which mobile operator will serve its final location. If the manufacturer must install a region-specific SIM at assembly, that uncertainty becomes inventory, SKU and logistics work. STMicroelectronics’ latest ST87M01 announcement tackles the problem at the connectivity layer: software-based SIM options, SGP.32 profile provisioning on the factory line and a driver for the Zephyr embedded operating system.

One module, three integration changes

On November 5, ST announced new options for the ST87M01 NB-IoT industrial module family. The first is Onomondo SoftSIM, a software-based SIM solution running on the module’s processing subsystem, which ST says removes the need for a separate physical SIM device. The second is support for in-factory operator-profile provisioning using the GSMA’s SGP.32 framework. The third is Zephyr ecosystem support: ST says the driver is available through Zephyr’s GitHub and includes network protocols such as UDP, TCP, HTTP, MQTT and CoAP, along with positioning features. ^{[1] [3]}

The manufacturing value is straightforward. A product team can assemble a common hardware variant, provision its network profile near the end of production and avoid storing a separate set of preconfigured SIMs for each destination. ST says the same SGP.32 framework supports factory provisioning and remote profile management in the field. That can simplify the handoff between manufacturing and deployment, especially for fleets that lack a screen or human operator. ^{[1] [2]}

The GSMA specification exists for IoT devices whose network or user interfaces are constrained. It describes the architecture for remote provisioning and management of eUICCs, rather than one vendor’s proprietary workflow. That matters because a device fleet may outlive its original connectivity plan. An operator profile is part of a lifecycle: installation, activation, possible switching, suspension, recovery and retirement. ^{[2] [4]}

A standard does not create a carrier relationship

SGP.32 makes the profile-management roles and interfaces more consistent; it does not guarantee coverage, roaming terms, price or service continuity. Before changing hardware or manufacturing flow, a device maker must confirm that its eSIM implementation, module firmware, profile manager and selected operators support the intended combination. It also needs credentials and policies that determine who can install, enable, disable or replace a profile.

SoftSIM and SGP.32 should not be collapsed into one feature. SoftSIM describes where SIM functionality is implemented in this ST offering; SGP.32 describes an IoT remote-provisioning framework for eSIM profiles. A fleet design may use one, the other or both, depending on the module variant and its commercial connectivity model. The announcement does not publish every operator pairing, service price or regional availability detail. Teams should confirm those specifics with ST and their connectivity provider before treating a production rollout as ready. ^{[1] [2]}

A manufacturing pilot should test more than whether a profile downloads. Verify the device’s identity and bootstrap path, the right operator profile for each destination, authentication and key custody, network attach, fallback behavior when provisioning fails, and an audit trail for every profile change. Define who owns remote changes after the product ships. A device that is unreachable or sealed inside a meter enclosure cannot depend on an engineer manually swapping a card in the field.

Zephyr support lowers one integration barrier

The driver addition gives firmware teams a public starting point inside Zephyr’s modem subsystem. The repository provides a practical signal that the module is being integrated into a broad open-source RTOS ecosystem, but a driver does not by itself validate every carrier, board, power mode or product-specific use case. Teams should review the supported features, hardware bindings, firmware version and sample behavior against their own device design. ^[3]

ST lists the family as LTE Cat NB2 Release 15 and publishes a small 12.8 × 10.6 mm package with multiple module variants, including options for GNSS, Wi-Fi positioning and Wireless M-Bus. The choices can help a product team converge radio, positioning and embedded software decisions around one module family. They also create configuration work: each option affects certifications, antenna design, firmware builds, power budgets and market access. ^[1]

A sensible first deployment is a limited batch of identical devices destined for different network regions. Compare the current SIM logistics with the proposed provisioning path, including provisioning failures and support work—not only SIM purchase price. Test recovery from a wrong profile and lost connectivity in a controlled setting before installing equipment in hard-to-reach sites.

ST’s update is valuable because it connects chip-level connectivity with the production process and a developer ecosystem. The promise is fewer regional hardware decisions before deployment. The operational work does not disappear; it moves toward profile governance, operator relationships and reliable recovery for devices expected to work unattended for years.

Related reading: device identity and secure IoT deployment and how durable product lifecycle choices shape systems.