While the GSMA’s SGP.32 v1.3 standard offers a promising shift towards flexible vehicle connectivity, industry adoption remains fragmented, with early deployments highlighting interoperability hurdles and the need for comprehensive lifecycle management.
The GSMA’s publication of SGP.32 v1.3 on 28 May 2026 marks an important step for automotive connectivity, but the market has not fully converged on the new version. In practice, much of the industry is still working from v1.2, which has become the main implementation and testing baseline. That gap matters for carmakers, whose vehicles may stay in service for 15 years or longer and whose supply chains need proof that components, software and provisioning systems work together reliably.
SGP.32 was designed for IoT devices that are managed remotely and may have no screen, camera or other user interface. The GSMA’s latest specification pairs the new architecture update with v1.2 conformance documents, which helps explain why vendors can claim support for SGP.32 while referring to different version sets. For procurement teams, a simple “supports SGP.32” statement is no longer enough. They need to know which specification was implemented, which test regime was passed and how far each supplier has progressed towards v1.3.
Commercial deployments are already beginning to emerge. Kigen launched what it described as the first market-ready eSIM IoT Remote Manager compliant with SGP.32 v1.2 in October 2024. In April 2026, Telenor IoT said it had started commercial delivery of standardised SGP.32 SIMs, while KORE and Kigen announced a partnership to deliver next-generation SGP.32 connectivity for global deployments. Even so, live demonstrations of remote profile changes across several devices only prove that the concept is workable, not that every combination of eUICC, eIM, SM-DP+ and modem will interoperate without difficulty.
For automotive manufacturers, the appeal of SGP.32 is structural. Earlier remote-provisioning approaches such as SGP.02 tended to lock an OEM into a single provisioning environment early in the vehicle lifecycle. By contrast, SGP.32 places an eSIM IoT Remote Manager, or eIM, between the vehicle and the profile provider, allowing profiles to be obtained later and reducing the need for physical intervention. That is especially relevant in markets such as Brazil, India and Turkey, where permanent-roaming rules can complicate a single global connectivity model. But the standard is not a shortcut around regulation: local profile rules, customer identification and data-handling obligations still have to be met country by country.
The bigger challenge is mixed-fleet management. Automotive programmes will not move from SGP.02 to SGP.32 in a single step, so operators will need one view across old and new vehicles, covering profile status, operator onboarding, billing and diagnostics. Industry groups and vendors are already positioning for that layer of orchestration. Thales has argued that some automotive proofs of concept prefer an IPAe model, where the IoT Profile Assistant sits on the eUICC, because it can reduce changes to the telematics control unit. Meanwhile, planned features such as Multiple Enabled Profiles in a future SGP.32 release could give vehicles separate profiles for telematics, infotainment and resilience. For OEMs, the real decision is no longer whether SGP.32 exists, but whether their supplier stack can prove interoperability, localisation and lifecycle control in production-like conditions.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
