Después de una década de lock-in, el SIM de IoT por fin es libre

El día que el operador sube el precio

Imagina que tienes 50.000 contadores de agua desplegados en cinco países. Cada uno lleva una eUICC SGP.02 cargada de fábrica con un perfil del Operador A. Tres años después tu contrato con A se vuelve insostenible — sube el precio, retira una banda que necesitas o sencillamente cierra el servicio M2M. Quieres mover toda la flota al Operador B.

Con SGP.02 esa migración es una pesadilla operativa. La eUICC depende de un SM-SR (Subscription Manager — Secure Routing) que casi siempre es propiedad del Operador A o de su socio. Para mover los dispositivos a un nuevo SM-SR — el famoso change-of-ownership — hace falta que los dos SM-SRs colaboren activamente. En la práctica, esa colaboración rara vez ocurre: el SM-SR saliente no tiene incentivo para soltar la flota, los contratos no la obligan, y la operación se atasca en una negociación bilateral que dura meses.

El problema no es teórico. La industria IoT lleva una década enviando dispositivos diseñados para 7-15 años de vida operativa con una elección de conectividad que en la práctica es irreversible. Eso es lo que SGP.32 viene a romper.

Qué teníamos antes y por qué no era suficiente

SGP.02 — el estándar M2M de la década pasada

Publicado por la GSMA en 2014, SGP.02 fue la primera respuesta seria al problema del eSIM para máquinas. Define dos plataformas servidor — SM-DP prepara los perfiles cifrados y SM-SR los entrega y los gestiona en remoto sobre OTA — y el SM-SR empuja los comandos por el canal del perfil activo.

Eso tiene dos problemas estructurales. Primero, el lock-in del SM-SR ya mencionado: el SM-SR es habitualmente del operador, y cambiar de SM-SR es una negociación contractual lenta cuando no imposible. Segundo, más sutil: si el perfil activo se queda sin cobertura, el SM-SR no puede alcanzar al dispositivo, y como el único canal para meterle un perfil nuevo es OTA sobre el perfil que no funciona, te toca recoger físicamente los equipos. En una flota de contadores enterrados, eso destruye el modelo de negocio.

SGP.22 — el estándar consumer, que asume que hay una persona

SGP.22 (2016, vigente y muy madura) es el modelo del eSIM en tu móvil. Sustituye SM-DP + SM-SR por un único SM-DP+ y añade un componente local en el dispositivo — el LPA (Local Profile Assistant) — que descarga y gestiona los perfiles desde una UI. El modelo es pull: el dispositivo va a buscar el perfil cuando alguien escanea un QR o introduce un código.

SGP.22 funciona perfectamente para teléfonos. No funciona para contadores. Asume que hay una pantalla donde se muestra el QR, un dedo que confirma la descarga, y un usuario que sabe qué operador quiere. Un sensor de presión en una tubería no tiene ninguna de esas tres cosas. Forzar SGP.22 en IoT exigía orquestar el LPA con scripts propietarios — funciona, pero rompe la interoperabilidad y nunca llegó a estandarizarse.

Los tres dolores que SGP.32 resuelve

1. Portabilidad real entre operadores

En SGP.32 desaparece el SM-SR como punto único de control. El dueño del dispositivo decide qué plataforma remota gestiona la eUICC, independientemente de quién fabricó el chip y de qué operador iba cargado de fábrica. No hace falta acuerdo del operador saliente: si tienes acceso criptográfico a la eUICC, puedes apuntarla a tu propio gestor.

La consecuencia comercial es directa: por primera vez en una década, una eUICC IoT se comporta como cualquier otro componente del BOM — algo que puedes reemplazar de proveedor sin tirar el dispositivo. Hasta SGP.32, la eUICC M2M era, de facto, una decisión de proveedor para toda la vida del producto.

2. Recuperación sin depender del operador actual

Como el canal de gestión ya no es OTA por el perfil activo sino una conexión IP que el dispositivo inicia, el agente local puede usar cualquier red IP disponible — Wi-Fi, otro operador celular, una red mesh — para descargar un perfil nuevo. El dispositivo deja de quedar atrapado en el lado equivocado de un apagado de banda o de un cambio regulatorio.

Esto cambia las garantías que puedes ofrecer en RFP. La frase «el dispositivo sobrevive a una caída del operador A si el sitio tiene cobertura de B» se vuelve verificable, no aspiracional.

3. Operaciones en bloque que de verdad escalan

En SGP.02, cambiar el operador de 10.000 dispositivos requería 10.000 comandos OTA pasando por el SM-SR del operador saliente, en horarios negociados, con tasa de éxito en torno al 70% y un par de meses de proyecto. En SGP.32, el gestor emite un paquete de cambio de perfil y lo entrega cuando el dispositivo se conecta, con reintentos integrados y trazabilidad por dispositivo. La operación deja de ser un proyecto y se convierte en un cambio de configuración.

Los dos roles nuevos: IPA y eIM

Para resolver lo anterior sin romper la separación de funciones que GSMA ha construido a lo largo de tres especificaciones, SGP.32 introduce dos roles nuevos. La parte 2 entra al detalle; aquí basta con saber quién es quién.

• IPA (IoT Profile Assistant): el equivalente al LPA de SGP.22, pero diseñado para dispositivos sin UI. Vive o bien dentro del device firmware (módem o aplicación), o bien como applet dentro de la propia eUICC. Es quien recibe instrucciones del gestor remoto, descarga el perfil desde el SM-DP+ y lo activa.
• eIM (eSIM IoT remote Manager): la plataforma remota que da órdenes al IPA. Lo crítico es que el eIM ya no es del operador móvil ni de la eUICC: lo opera quien quiera el dueño del dispositivo. Puede ser el OEM, un integrador, un MVNO, o el propio cliente final. Esa libertad es lo que rompe el lock-in histórico.
• SM-DP+: el mismo que en SGP.22. Sigue siendo el componente que prepara y firma criptográficamente el perfil. Cualquier SM-DP+ certificado por GSMA sirve.

Lo que esto desbloquea comercialmente

Las consecuencias prácticas van más allá del «ahora puedes cambiar de operador». Tres son las que cambian de verdad la conversación con un cliente IoT:

• Una sola SKU para varios mercados. Un mismo dispositivo, con la misma eUICC, puede llevar un perfil bootstrap genérico y recibir el perfil del operador local cuando se enciende en el país de destino. Antes de SGP.32, eso exigía hardware específico por país o eUICC SGP.02 con SM-SR cooperativo — ninguna de las dos cosas escalaba.
• Flotas controladas por el OEM, no por el operador. El fabricante de un robot agrícola puede mantener un eIM propio y gestionar la conectividad como una capacidad de producto, no como un servicio comprado al operador. Eso modifica la cadena de valor y, en algunos casos, la cuenta de resultados.
• Roll-back nativo a la versión anterior del perfil. Si un intento de cambio de perfil deja al dispositivo incomunicado, el IPA tiene capacidad de volver al perfil previo de manera estandarizada. Antes era una combinación de heurísticas locales y rezos. La parte 2 entra en el detalle técnico.

Dónde estamos en la curva de adopción

La especificación tiene tres hitos públicos: v1.0 publicada por GSMA en mayo de 2023 (con la corrección v1.0.1 en julio de 2023), v1.1 en abril de 2024 — la versión que la GSMA usa hoy como referencia normativa estable — y v1.2 finalizada en diciembre de 2024. Más importante para una decisión de compra: las pruebas de conformidad y los programas de certificación GSMA (para eUICC, SM-DP+ y la propia IPA) empezaron a estar disponibles a lo largo de 2025. Ese hito es el «semáforo verde» práctico que desbloquea las compras corporativas serias.

En el lado del silicio, Qualcomm es el actor más visible del mercado de módulos celulares con firmware IPA-capable, y la documentación industrial (Kigen, Trusted Connectivity Alliance) sitúa habitualmente a Telit y Fibocom como integradores de referencia. La realidad es desigual por módulo: pide al fabricante la matriz de soporte exacta y la versión de firmware mínima antes de comprometerte.

En el lado del eUICC, Kigen ha sido el actor más rápido del mercado — eUICCs SGP.32 en producción a lo largo de 2024 y un eIM compatible con v1.2 anunciado en octubre de 2024. IDEMIA obtuvo su certificación GSMA SGP.32 en abril de 2025. Thales y otros grandes proveedores de eSIM están en distintas fases del proceso. El catálogo de plataformas eIM independientes está creciendo en 2025-2026, pero sigue siendo un mercado joven.

Preguntas frecuentes

Qué viene en las dos siguientes entregas

La parte 2 entra en la arquitectura técnica. Las dos variantes físicas (IPA en el dispositivo vs. IPA dentro de la eUICC) y por qué elegirías una u otra. La interfaz ESipa entre IPA y eIM, con sus bindings sobre CoAP y HTTPS. Los paquetes eIM que llevan instrucciones de descarga y de cambio de perfil. Las cadenas de certificados y la autenticación mutua. Y los flujos completos: descarga directa, descarga indirecta y rollback.

La parte 3 es la guía de despliegue. Qué piezas comprar y a quién, cómo elegir entre un eIM propio o uno operado por un tercero, qué incluir en el RFP, cómo gestionar la flota en bloque sin perderse, y cuál es el estado real de interoperabilidad entre fabricantes de eUICC y de SM-DP+ a día de hoy.

Si vienes a SGP.32 con prisa, el briefing corto de 5 minutos sigue siendo el resumen ejecutivo. Esta serie es para cuando ya has decidido que quieres entenderlo de verdad.