La primera bifurcación: IPAd o IPAe
Antes de mirar mensajes, hay una decisión arquitectónica que define todo el resto: dónde vive el IPA (IoT Profile Assistant). SGP.32 admite dos variantes físicas, y el dispositivo elige una en tiempo de diseño.
IPAd — IPA en el dispositivo
El IPA corre como software del dispositivo: bien dentro del firmware del módem, bien como aplicación en el procesador anfitrión. Habla con el eUICC por la interfaz APDU tradicional, igual que cualquier otra aplicación que use el SIM.
Lo que ganas: control. El OEM decide cuándo el IPA intenta refrescar el perfil, qué hace ante un fallo de red, qué eventos emite a la nube. Si tu producto tiene un pipeline OTA decente, esta variante es una palanca real — puedes evolucionar la lógica del IPA con cada release de firmware sin tocar el eUICC.
Lo que cuestas: superficie de ataque y código. El IPA es software con secretos criptográficos; cualquier compromiso del firmware del módem es un compromiso potencial del IPA. Y ocupa código — entre 50 y 200 KB dependiendo de implementación.
IPAe — IPA dentro del eUICC
El IPA corre como applet Java Card dentro del propio eUICC. El dispositivo lo ve como otra función del SIM y le habla por APDU; toda la lógica de descarga, activación y rollback ocurre dentro del chip.
Lo que ganas: integración casi turnkey. El fabricante del eUICC entrega el chip con el IPAe certificado por GSMA y validado. No tienes que añadir lógica al firmware del dispositivo más allá de exponer la conexión IP al applet. Para dispositivos con presupuesto de código apretado, es la opción razonable.
Lo que cuestas: flexibilidad. Cualquier comportamiento custom — reintentos especiales, instrumentación de telemetría, integración con un sistema de eventos propio — está limitado a lo que el applet del fabricante del chip permita.
El reparto completo: seis actores
Tres actores externos al dispositivo, más cinco componentes dentro del eUICC. Vale la pena saber qué hace cada uno antes de mirar el protocolo.
Lo que está fuera
- IPA (IoT Profile Assistant): el componente que ya conoces. En el dispositivo (IPAd) o en el eUICC (IPAe). Es el cliente en la conversación con el eIM.
- eIM (eSIM IoT remote Manager): el servidor que da órdenes al IPA. Tres responsabilidades: configurar al IPA (a quién hablar, con qué certificados), entregarle paquetes de instrucciones, y registrar el estado que el IPA reporta.
- SM-DP+ (Subscription Manager — Data Preparation): el servidor del operador móvil. Prepara, cifra y firma el perfil que el eUICC va a recibir. Es el mismo SM-DP+ que en SGP.22, y la GSMA exige certificación.
- SM-DS (Subscription Manager — Discovery Service, opcional): un servidor de descubrimiento. Cuando el IPA no sabe a qué SM-DP+ apuntar para encontrar un perfil, le pregunta al SM-DS y éste le devuelve la dirección. Útil para dispositivos sin bootstrap pre-configurado.
Lo que está dentro del eUICC
- ECASD (eUICC Controlling Authority Security Domain): la raíz criptográfica del chip. Contiene el certificado de identidad del eUICC, firmado por el fabricante (Kigen, IDEMIA, Thales, etc.) bajo la jerarquía GSMA. Todo lo demás deriva de aquí.
- ISD-R (Issuer Security Domain — Root): el dominio de gestión. Sabe qué perfiles hay cargados, cuál está activo, y ejecuta las órdenes del IPA («activa este, desactiva ese»).
- ISD-P (Issuer Security Domain — Profile): hay uno por perfil cargado. Cada ISD-P encapsula un perfil completo de operador (IMSI, Ki, configuración de red) con sus propias claves de cifrado.
- Telecom Framework: la fachada que ve el módem. Expone la interfaz SIM estándar (PIN, IMSI, autenticación A3/A5) al firmware del módem, quien no necesita saber que detrás hay un eUICC.
- Profile Package Interpreter: parsea el paquete cifrado que el SM-DP+ entrega y lo desempaqueta en un ISD-P nuevo. Es la pieza que decodifica el formato TLV de perfil estandarizado por GSMA.
ESipa: la conversación nueva
La interfaz IPA ↔ eIM se llama ESipa. Es el aporte protocolar propio de SGP.32 — no existe en SGP.22 — y está diseñado para las peculiaridades del IoT: redes inestables, dispositivos detrás de NAT, anchos de banda escasos, latencias altas.
Dos bindings: CoAP y HTTPS
ESipa define dos transportes para los mismos mensajes lógicos:
- CoAP sobre UDP con DTLS: el binding nativo IoT. Cabeceras de pocos bytes, pensado para redes con MTU pequeño y para conservar batería. Default en LPWA (NB-IoT, LTE-M).
- HTTPS sobre TCP con TLS: el binding nativo IT. Más fácil de depurar, atraviesa corporate proxies sin trucos, encaja en infraestructuras de monitorización estándar. Default en 4G/5G y en dispositivos con ancho de banda holgado.
Los dos bindings transportan los mismos tipos de mensaje al nivel lógico — el IPA y el eIM no saben (ni les importa) qué transporte usa la otra parte. El módem decide en función de capacidades de red.
Autenticación mutua
TLS o DTLS, con certificados a ambos lados. El IPA prueba que es una instancia legítima de IPA presentando el certificado de identidad del eUICC (firmado por el fabricante del chip bajo la cadena GSMA). El eIM prueba que es el eIM al que el dispositivo fue configurado para hablar, presentando su propio certificado firmado bajo la cadena del operador del eIM.
Cualquier intento de un actor que no tenga el certificado correcto se cae en el handshake. Ése es el corazón del modelo de confianza: no hay shared secrets ni tokens revocables manualmente; todo es PKI X.509 estándar.
Lo que viaja por el cable: tres tipos de mensaje
ESipa define tres tipos de mensaje primarios entre eIM e IPA. Los reconocerás en cualquier traza de red o log:
EuiccPackageRequest (eIM → IPA)
Es el mensaje que lleva instrucciones para el eUICC. El payload puede ser una de tres cosas:
- eUICC Configuration Order (eCO): cambia el estado de configuración del eUICC sin tocar perfiles individuales — actualizar metadatos, registrar el eIM autorizado, ajustar políticas globales.
- Profile State Management Order (PSMO): opera sobre un perfil concreto. «Activa el perfil 3», «desactiva el perfil 1», «borra el perfil 5». Es el verbo de gestión de flota más común.
- Profile Download Trigger: arranca una descarga de perfil desde un SM-DP+ concreto. Lleva la dirección del SM-DP+, el ID de activación y los parámetros que el IPA necesita para iniciar la sesión.
IpaEuiccDataRequest (eIM → IPA)
Pregunta «¿qué tienes ahora mismo?» El IPA responde con un IpaEuiccDataResponse que enumera los perfiles cargados, cuál está activo, el espacio disponible y las capacidades del eUICC. Es lo que el eIM usa para sincronizar su modelo del estado de la flota.
EimAcknowledgements (IPA → eIM)
Recibos asíncronos. Cuando el IPA termina de ejecutar un EuiccPackageRequest, responde con un EimAcknowledgement que dice «ok, se ejecutó», o «falló, este es el código de error». El eIM lo correlaciona con el paquete original y actualiza el estado.
Los dos caminos por los que un perfil llega a casa
Cuando el eIM emite un Profile Download Trigger, el IPA tiene que ir a buscar el perfil al SM-DP+. SGP.32 define dos caminos para esa transferencia.
Descarga directa
El IPA abre una conexión TLS directamente con el SM-DP+ que le indicó el eIM, autentica mutuamente (la Common Mutual Authentication definida por GSMA), pide el perfil, lo recibe cifrado de extremo a extremo para el eUICC, y lo instala. El eIM no participa más allá del trigger.
Se usa cuando el IPA tiene conectividad IP normal y el SM-DP+ es alcanzable desde la red en la que el dispositivo está conectado.
Descarga indirecta
Cuando el IPA no puede alcanzar el SM-DP+ directamente — por ejemplo, está detrás de un APN privado que sólo permite salir hacia los servidores corporativos, o en una red operadora que no enruta a hosts públicos arbitrarios — el eIM actúa de proxy. El eIM descarga el perfil del SM-DP+ por su lado, y lo entrega al IPA a través del canal ESipa que ya existía.
Importante: el perfil sigue cifrado de extremo a extremo para el eUICC. El eIM transporta el bloque cifrado pero no tiene las claves para descifrarlo. Eso es lo que permite que un eIM operado por un tercero sea seguro: ve cuándo se mueven los perfiles, pero no qué hay dentro.
Cuando la migración falla: el procedimiento de rollback
Esta es la característica que convierte SGP.32 de una especificación útil en algo en lo que confiarías para una flota de 50.000 dispositivos. En SGP.02, una migración fallida dejaba al dispositivo en silencio y alguien tenía que ir físicamente a buscarlo. En SGP.32, el IPA puede volver atrás solo.
La mecánica es esta: antes de activar un perfil nuevo, el IPA registra cuál era el perfil anterior y el momento exacto en que lo desactivó. Si pasado un plazo configurable (típicamente 24 a 72 horas) el eUICC no recibe del eIM un mensaje de «commit» a través de la red del perfil nuevo, el IPA asume que la migración no funcionó y reactiva el perfil anterior.
Para que esto funcione bien, el eUICC necesita una noción razonable del tiempo. Si el dispositivo tiene GPS o NTP, lo resuelve por ahí; si no, hay que poblar el reloj del eUICC desde el módem en cada arranque. La especificación deja esto al integrador, pero es la trampa práctica más común en pilotos de SGP.32.
Quién avala a quién: la cadena de certificados
Cuatro raíces criptográficas, organizadas en una jerarquía que la GSMA define en SGP.21:
- GSMA Root CA: la raíz global. Firma las CAs de cada fabricante de eUICC y de cada operador de SM-DP+.
- EUM CA (eUICC Manufacturer): una por fabricante. Firma los certificados de identidad de cada eUICC que sale de fábrica.
- SM-DP+ CA: una por operador del SM-DP+. Firma el certificado de cada instancia operativa de SM-DP+.
- eIM CA: tradicionalmente la CA propia del operador del eIM. La GSMA está formalizando una lista común para facilitar interoperabilidad, pero a día de hoy es la pieza menos estandarizada.
La revocación se gestiona con CRL/OCSP estándar. Si un eUICC queda comprometido (extracción del chip, fuga de claves), su certificado se revoca; a partir de ese momento ni el eIM ni el SM-DP+ aceptan handshakes con esa identidad.
Lo que la mayoría de los pilotos hace mal
- Restricciones de red. Si tu APN privado o tu IP fija no enruta a hosts arbitrarios, necesitarás descarga indirecta. Comprueba esto con el operador del APN antes de empezar; suele requerir añadir el rango del SM-DP+ a la lista permitida.
- Sincronía de reloj. El rollback depende de saber qué hora es. Dispositivos sin GPS ni NTP fiable son los que más sufren. Soluciónalo con NITZ desde la red móvil o con un campo de sello temporal en cada mensaje ESipa.
- Memoria del eUICC. Cada perfil ocupa entre 30 y 100 KB en el eUICC. Los eUICC industriales típicos guardan entre 4 y 8 perfiles simultáneos; eso fija el ancho de tu estrategia de fallback y de multi-mercado.
- Path de actualización del IPA. Si optas por IPAd, el código del IPA viaja con tu firmware. Planifica el camino de actualización del propio IPA con la misma seriedad con la que planificas el de la aplicación.
- Pruebas de roaming. El SM-DP+ puede estar en otro continente. Comprueba latencia y MTU desde el país donde el dispositivo se va a desplegar — los pilotos a veces funcionan en la oficina pero fallan en campo por timeouts.
Preguntas frecuentes
¿Qué diferencia hay en la práctica entre IPAd e IPAe?
El IPAd (IPA en el dispositivo) vive en el firmware del módem o de la aplicación, así que lo controla el OEM y puede tener lógica de reintento o instrumentación a medida; a cambio, ocupa código en el dispositivo y aumenta la superficie de ataque. El IPAe (IPA en el eUICC) corre como applet Java Card dentro del propio eUICC: lo mantiene el fabricante del chip, hay menos código en el dispositivo y la integración es prácticamente «encender y olvidarse», a costa de menos personalización. Si el dispositivo es nuevo y tienes un pipeline serio de OTA, IPAd te da más palanca. Si el coste de integración es lo que manda, IPAe.
¿Tengo que operar mi propio eIM?
No. El eIM puede ser propio del OEM, operado por un integrador, o contratado a un MVNO que lo ofrezca como servicio. Lo importante es que dejas de estar atado al operador de la eUICC, no que tengas que montar la plataforma. La parte 3 entra en cuándo tiene sentido cada opción.
¿Qué pasa si una descarga de perfil se interrumpe a mitad?
El IPA no activa un perfil parcial. Si la transferencia se corta, el dispositivo sigue con el perfil anterior intacto y el eIM lo verá en el siguiente IpaEuiccDataResponse. La reintenta cuando vuelva a haber conectividad. Esto es muy distinto de SGP.02, donde una migración a medias podía dejar al dispositivo en un estado mixto.
¿El eIM puede ver el perfil en claro?
No. El perfil va cifrado de extremo a extremo entre el SM-DP+ y el eUICC concreto que lo va a recibir. En la descarga indirecta el eIM transporta el bloque cifrado, pero no tiene las claves para descifrarlo. Eso es lo que hace que el eIM pueda ser operado por un tercero sin comprometer la confidencialidad del perfil.
¿SGP.32 exige LPWA (NB-IoT, LTE-M) o también funciona en 4G/5G estándar?
Funciona en cualquier portador IP. ESipa puede correr sobre CoAP/DTLS (típico de LPWA, optimizado en bytes) o sobre HTTPS/TLS estándar (típico de 4G/5G y de despliegues con corporate proxy). El módem y el SO del dispositivo deciden qué binding usar; el resto del protocolo es idéntico.
Qué viene en la parte 3
La parte 3 es el guía de despliegue. Qué piezas comprar y a quién, el tradeoff entre operar un eIM propio o contratarlo, multi-mercado con una sola SKU de hardware, gestión en bloque sin perder el control, el estado real de la interoperabilidad entre fabricantes en 2026, y la checklist de RFP larga.
Si llegaste aquí buscando el resumen ejecutivo, el briefing corto de 5 minutos sigue siendo el punto de entrada. Si quieres recapitular por qué SGP.32 existe antes de tomar decisiones técnicas, vuelve a la parte 1.