Após uma década de lock-in, o SIM IoT está finalmente livre

O dia em que o operador sobe o preço

Imagine que tem 50 000 contadores de água instalados em cinco países. Cada um leva um eUICC SGP.02 carregado de fábrica com um perfil do Operador A. Três anos depois o seu contrato com A torna-se insustentável — sobem o preço, retiram uma banda de que precisa, ou simplesmente fecham o serviço M2M. Quer mover a frota inteira para o Operador B.

Com SGP.02 essa migração é um pesadelo operacional. O eUICC depende de um SM-SR (Subscription Manager — Secure Routing) que é quase sempre propriedade do Operador A ou do seu parceiro. Para mover os dispositivos para um SM-SR novo — o famoso change-of-ownership — é necessário que os dois SM-SRs cooperem activamente. Na prática, essa cooperação raramente acontece: o SM-SR a sair não tem incentivo para libertar a frota, os contratos não o obrigam, e a operação fica entalada numa negociação bilateral que se arrasta durante meses.

O problema não é teórico. A indústria IoT passou uma década a enviar dispositivos desenhados para 7-15 anos de vida útil com uma escolha de conectividade que é, na prática, irreversível. É isso que SGP.32 vem partir.

O que tínhamos antes e porque não era suficiente

SGP.02 — o standard M2M da década passada

Publicado pela GSMA em 2014, SGP.02 foi a primeira resposta séria ao problema do eSIM para máquinas. Define duas plataformas servidor — SM-DP prepara os perfis cifrados e SM-SR entrega-os e gere-os remotamente sobre OTA — e o SM-SR empurra os comandos pelo canal do perfil activo.

Isto tem dois problemas estruturais. Primeiro, o lock-in do SM-SR já mencionado: o SM-SR pertence habitualmente ao operador, e mudar de SM-SR é uma negociação contratual lenta quando não impossível. Segundo, mais subtil: se o perfil activo fica sem cobertura, o SM-SR não consegue alcançar o dispositivo, e como o único canal para meter-lhe um perfil novo é OTA pelo perfil que não funciona, tem de recolher fisicamente os equipamentos. Numa frota de contadores enterrados, isso destrói o modelo de negócio.

SGP.22 — o standard consumer, que assume que existe uma pessoa

SGP.22 (2016, em uso e muito maduro) é o modelo do eSIM no seu telemóvel. Substitui SM-DP + SM-SR por um único SM-DP+ e adiciona um componente local no dispositivo — o LPA (Local Profile Assistant) — que descarrega e gere os perfis a partir de uma UI. O modelo é pull: o dispositivo vai buscar o perfil quando alguém digitaliza um QR ou introduz um código.

SGP.22 funciona perfeitamente para telemóveis. Não funciona para contadores. Assume que há um ecrã onde se mostra o QR, um dedo que confirma o download, e um utilizador que sabe qual operador quer. Um sensor de pressão num tubo não tem nenhuma das três. Forçar SGP.22 em IoT exigia orquestrar o LPA com scripts proprietários — funciona, mas quebra a interoperabilidade e nunca chegou a ser estandardizado.

As três dores que SGP.32 resolve

1. Portabilidade real entre operadores

Em SGP.32 desaparece o SM-SR como ponto único de controlo. O dono do dispositivo decide que plataforma remota gere o eUICC, independentemente de quem fabricou o chip e que operador foi carregado de fábrica. Não é preciso o consentimento do operador a sair: se tem acesso criptográfico ao eUICC, pode apontá-lo ao seu próprio gestor.

A consequência comercial é directa: pela primeira vez numa década, um eUICC IoT comporta-se como qualquer outro componente do BOM — algo que pode trocar de fornecedor sem deitar fora o dispositivo. Até SGP.32, o eUICC M2M era, de facto, uma decisão de fornecedor para toda a vida do produto.

2. Recuperação sem depender do operador actual

Como o canal de gestão já não é OTA pelo perfil activo mas uma ligação IP que o dispositivo inicia, o agente local pode usar qualquer rede IP disponível — Wi-Fi, outro operador celular, uma rede mesh — para descarregar um perfil novo. O dispositivo deixa de ficar preso do lado errado de um desligamento de banda ou de uma alteração regulamentar.

Isto muda as garantias que pode oferecer num RFP. A frase «o dispositivo sobrevive a uma queda do operador A se o local tiver cobertura de B» torna-se verificável, não aspiracional.

3. Operações em massa que escalam mesmo

Em SGP.02, mudar o operador de 10 000 dispositivos exigia 10 000 comandos OTA encaminhados pelo SM-SR do operador a sair, em janelas negociadas, com taxa de sucesso desigual e um par de meses de projecto. Em SGP.32, o gestor emite um pacote de mudança de perfil e entrega-o quando cada dispositivo se liga, com retries integrados e rastreabilidade por dispositivo. A operação deixa de ser um projecto e torna-se uma alteração de configuração.

Os dois papéis novos: IPA e eIM

Para resolver o que está acima sem partir a separação de funções que a GSMA construiu ao longo de três especificações, SGP.32 introduz dois papéis novos. A parte 2 entra ao detalhe; aqui basta saber quem é quem.

• IPA (IoT Profile Assistant): o equivalente ao LPA de SGP.22, mas desenhado para dispositivos sem UI. Vive ou dentro do firmware do dispositivo (modem ou aplicação), ou como applet dentro do próprio eUICC. É o componente que recebe instruções do gestor remoto, descarrega o perfil do SM-DP+ e activa-o.
• eIM (eSIM IoT remote Manager): a plataforma remota que dá ordens ao IPA. O ponto crítico é que o eIM já não pertence ao operador nem ao fabricante do eUICC: opera-o quem o dono do dispositivo escolher. Pode ser o OEM, um integrador, um MVNO, ou o cliente final. Essa liberdade é o que parte o lock-in histórico.
• SM-DP+: o mesmo de SGP.22. Continua a ser o componente que prepara e assina criptograficamente o perfil. Qualquer SM-DP+ certificado pela GSMA serve.

O que isto desbloqueia comercialmente

As consequências práticas vão além do «agora pode mudar de operador». Três são as que mudam realmente a conversa com um cliente IoT:

• Uma só SKU para vários mercados. O mesmo dispositivo, com o mesmo eUICC, pode levar um perfil bootstrap genérico e receber o perfil do operador local quando se liga no país de destino. Antes de SGP.32, isso exigia hardware específico por país ou eUICC SGP.02 com SM-SR cooperativo — nenhuma das duas escalava.
• Frotas controladas pelo OEM, não pelo operador. O fabricante de um robot agrícola pode manter um eIM próprio e gerir a conectividade como uma capacidade de produto, não como um serviço comprado ao operador. Isso modifica a cadeia de valor e, em alguns casos, a conta de resultados.
• Rollback nativo para o perfil anterior. Se uma tentativa de mudança de perfil deixa o dispositivo incomunicável, o IPA tem capacidade para voltar ao perfil anterior de maneira estandardizada. Antes era uma combinação de heurísticas locais e rezas. A parte 2 entra no detalhe técnico.

Onde estamos na curva de adopção

O standard tem três marcos públicos: v1.0 publicada pela GSMA em maio de 2023 (com a correcção v1.0.1 em julho de 2023), v1.1 em abril de 2024 — a versão que a GSMA usa hoje como referência normativa estável — e v1.2 finalizada em dezembro de 2024. Mais importante para uma decisão de compra: os testes de conformidade e os programas de certificação GSMA (para eUICC, SM-DP+ e o próprio IPA) começaram a estar disponíveis ao longo de 2025. Esse marco é o «semáforo verde» prático que desbloqueia as compras corporativas sérias.

No lado do silício, Qualcomm é o player mais visível do mercado de módulos celulares com firmware IPA-capable, e a documentação industrial (Kigen, Trusted Connectivity Alliance) cita habitualmente Telit e Fibocom como integradores de referência. A realidade é desigual por módulo: peça ao fabricante a matriz de suporte exacta e a versão de firmware mínima antes de se comprometer.

No lado do eUICC, Kigen foi o mais rápido do mercado — eUICCs SGP.32 em produção ao longo de 2024 e um eIM compatível com a v1.2 anunciado em outubro de 2024. A IDEMIA obteve a sua certificação GSMA SGP.32 em abril de 2025. A Thales e outros grandes fornecedores de eSIM estão em diferentes fases do processo. O catálogo de plataformas eIM independentes está a crescer em 2025-2026, mas continua a ser um mercado jovem.

Perguntas frequentes

O que vem nas duas entregas seguintes

A parte 2 entra na arquitectura técnica. As duas variantes físicas (IPA no dispositivo vs. IPA dentro do eUICC) e porque escolheria uma ou a outra. A interface ESipa entre IPA e eIM, com os seus bindings sobre CoAP e HTTPS. Os pacotes eIM que carregam instruções de download e de mudança de perfil. Cadeias de certificados e autenticação mútua. E os fluxos completos: download directo, download indirecto e rollback.

A parte 3 é o guia de implementação. O que comprar e a quem, como decidir entre correr o seu próprio eIM ou contratá-lo externamente, o que incluir no RFP, como gerir a frota em massa sem perder o controlo, e o estado real da interoperabilidade entre fabricantes de eUICC e de SM-DP+ hoje.

Se chegou a SGP.32 com pressa, o briefing curto de 5 minutos continua a ser o resumo executivo. Esta série é para quando já decidiu que quer entender a sério.