Introducción: La Insuficiencia del Paradigma SIM Tradicional en Entornos M2M
Durante décadas, la gestión de la conectividad celular en dispositivos máquina a máquina (M2M) dependió de un modelo operativamente rígido: una tarjeta SIM física vinculada a un único operador de red móvil (MNO), configurada en fábrica o en el momento del despliegue, imposible de reprovisionar de forma remota sin intervención manual. En implantaciones de baja escala, esta limitación era gestionable. En despliegues de miles o decenas de miles de dispositivos distribuidos geográficamente —medidores inteligentes, pasarelas industriales, sistemas de telemática vehicular, sensores de infraestructura crítica—, el modelo se convierte en un cuello de botella operacional de primer orden.
La eUICC (embedded Universal Integrated Circuit Card) resuelve el problema en la capa de hardware: un módulo SIM soldado a la placa base del dispositivo, reprogramable mediante actualizaciones de perfil remoto. Sin embargo, la eUICC es únicamente el soporte físico. El vector crítico es el protocolo de aprovisionamiento remoto que gobierna cómo se descargan, instalan, habilitan y eliminan los perfiles de operador sobre ese soporte. Es en esta capa donde la GSMA (GSM Association) ha desarrollado, revisado y estandarizado los marcos normativos que articulan el ecosistema eSIM para el segmento M2M: primero el SGP.02 (a menudo referenciado en su iteración de referencia de arquitectura como SGP.22 en la literatura técnica de producto), y posteriormente el SGP.32, la especificación que define el aprovisionamiento eSIM para IoT de próxima generación.
Este artículo analiza la arquitectura funcional de ambas especificaciones, examina sus diferencias estructurales con rigor técnico, identifica los escenarios de aplicación donde SGP.32 ofrece ventajas determinantes, y concluye evaluando cómo plataformas de gestión de dispositivos como Teltonika RMS y Robustel RCMS materializan las capacidades normativas de SGP.32 en productos comerciales concretos.
El Marco SGP.22: Fundamentos y Limitaciones Operacionales
Arquitectura y Componentes Funcionales
La especificación SGP.22 (Remote SIM Provisioning for M2M) establece la arquitectura de referencia para el aprovisionamiento remoto de eSIM en dispositivos M2M. Su arquitectura descansa sobre tres entidades funcionales centrales: el SM-DP (Subscription Manager – Data Preparation), el SM-SR (Subscription Manager – Subscription Repository), y la propia eUICC del dispositivo.
El SM-DP es responsable de la preparación criptográfica de los perfiles de operador. Cifra el perfil de conectividad con la clave pública de la eUICC destino, garantizando que únicamente esa eUICC específica puede descifrar e instalar el perfil. Este proceso implica la generación de Profile Packages cifrados conforme al estándar ASN.1 (Abstract Syntax Notation One), estructurados según los tipos de perfil definidos en SGP.02: perfiles de operador completos, perfiles provisionales o perfiles de bootstrapping.
El SM-SR gestiona el inventario de eUICCs, el estado de los perfiles instalados en cada una, y la entrega segura de los paquetes de perfil preparados por el SM-DP. La comunicación entre SM-SR y eUICC se realiza a través del protocolo CAT-TP (Card Application Toolkit Transport Protocol) sobre BIP (Bearer Independent Protocol), lo que establece una dependencia directa del canal de datos del dispositivo para ejecutar operaciones de gestión. Esto introduce una primera restricción operacional significativa: el dispositivo debe estar activo, con conectividad de datos operativa, y el SM-SR debe tener capacidad de iniciación de sesión hacia la eUICC, lo que en entornos con conectividad intermitente o restringida genera ventanas de gestión problemáticas.
Mecanismo de Gestión de Perfiles
En SGP.22, cada eUICC está vinculada a un único SM-SR en un momento dado. La transferencia de una eUICC entre SM-SRs —operación denominada Ownership Transfer— requiere un proceso de cambio de custodia (Change of Subscription Management) que implica coordinación explícita entre el SM-SR origen, el SM-SR destino y el SM-DP correspondiente. Esta operación no solo introduce latencia operacional, sino que exige acuerdos contractuales y de interoperabilidad técnica previos entre las partes, lo que en la práctica limita la portabilidad real de las eUICCs entre plataformas de diferentes vendedores.
El modelo de seguridad en SGP.22 se sustenta en infraestructura de clave pública (PKI) gestionada por la GSMA a través de la CI (Certificate Issuer), que firma los certificados de las eUICCs y de las entidades SM. El protocolo de autenticación mutua entre SM-SR y eUICC utiliza SCP80 (Secure Channel Protocol 80) y SCP81 para el establecimiento del canal seguro. Ambos protocolos, derivados de GlobalPlatform, presentan limitaciones de eficiencia computacional notables en eUICCs de gama baja, frecuentes en sensores IoT de coste reducido, donde los tiempos de procesamiento criptográfico pueden extenderse significativamente.
Restricciones en el Modelo Multioperador
Una de las fricciones más evidentes de SGP.22 en despliegues IoT de gran escala es la arquitectura de acoplamiento entre SM-DP y SM-SR. Cada perfil preparado por un SM-DP determinado solo puede ser entregado a través del SM-SR con el que ese SM-DP tiene acuerdo. La existencia de múltiples MNOs en el portafolio de conectividad de un despliegue exige, en consecuencia, la coordinación de múltiples pares SM-DP/SM-SR, lo que eleva la complejidad de integración y multiplica los puntos de fallo potenciales en la cadena de aprovisionamiento.
Esta arquitectura fue concebida para un contexto donde el operador de la red y el fabricante del dispositivo mantenían relaciones bilaterales bien establecidas. En el ecosistema IoT moderno, caracterizado por agregadores de conectividad, MNOs virtuales (MVNOs), y la gestión centralizada de flotas heterogéneas, esta rigidez estructural se convierte en un impedimento técnico real.
SGP.32: Arquitectura de Nueva Generación para IoT Masivo
Principios de Diseño y Motivación Normativa
SGP.32 (eSIM IoT Remote SIM Provisioning) emerge como respuesta directa a las limitaciones arquitectónicas de SGP.22 en el contexto de dispositivos IoT con capacidades computacionales y de conectividad reducidas. La especificación, publicada por la GSMA, introduce modificaciones fundamentales tanto en el modelo de entidades funcionales como en los protocolos de comunicación y gestión.
El principio rector de SGP.32 es la reducción de la complejidad operacional en el dispositivo (Device Complexity Reduction), trasladando la inteligencia de gestión hacia la plataforma de red y minimizando los requisitos computacionales sobre la eUICC. Paralelamente, el estándar introduce el concepto de IoT Profile Assistant (IPA), una entidad lógica que puede residir en el dispositivo o externalizarse a la red, actuando como intermediario entre la eUICC y la infraestructura de gestión remota.
La Entidad IPA y la Arquitectura Funcional Desacoplada
La introducción del IPA (IoT Profile Assistant) representa el cambio arquitectónico más relevante de SGP.32 respecto a SGP.22. En SGP.22, la lógica de gestión de perfiles residía en el SM-SR, que debía iniciar sesiones directas hacia la eUICC. En SGP.32, el IPA actúa como agente local que puede solicitar activamente operaciones al servidor de gestión (SM-DS y SM-DP+), invirtiendo la dirección del flujo de control.
Esta inversión de iniciativa tiene consecuencias operacionales de primer orden. Los dispositivos IoT frecuentemente operan detrás de NAT (Network Address Translation), con direccionamiento IP dinámico, o en redes con conectividad periódica (LPWAN, NB-IoT, LTE-M). En SGP.22, el SM-SR requería alcanzabilidad directa hacia el dispositivo, lo que en estos contextos exigía mecanismos adicionales de push sobre la capa de aplicación. En SGP.32, el IPA puede consultar el SM-DS (Subscription Manager – Discovery Server) en los momentos en que el dispositivo dispone de conectividad, recuperar las notificaciones de operaciones pendientes, y ejecutar el proceso de descarga de perfil de forma autónoma. Este modelo es conceptualmente análogo al patrón pull o polling en protocolos de gestión de dispositivos, pero implementado dentro del marco normativo GSMA.
SM-DP+ y la Integración de Funciones de Preparación y Repositorio
En SGP.32 (en consonancia con la arquitectura de SGP.22 para consumidor, SGP.21/SGP.22 RSP), el SM-DP (Data Preparation) y el SM-SR (Subscription Repository) se fusionan en la entidad unificada SM-DP+ (Subscription Manager – Data Preparation Plus). Esta consolidación elimina la dependencia de coordinación inter-plataforma que caracterizaba a SGP.22 M2M, donde la separación entre SM-DP y SM-SR generaba fricción operacional. El SM-DP+ asume la responsabilidad integral del ciclo de vida del perfil: preparación criptográfica, almacenamiento, gestión del estado y entrega segura.
El protocolo de comunicación entre el SM-DP+ y la eUICC evoluciona igualmente. SGP.32 adopta HTTPS como protocolo de transporte, abandonando la dependencia de CAT-TP/BIP presente en SGP.22. Este cambio tiene implicaciones técnicas directas: HTTPS es compatible con prácticamente cualquier pila de conectividad IP estándar, elimina la necesidad de soporte de protocolos específicos de capa de aplicación en la plataforma de red del operador, y facilita la integración con arquitecturas de backend corporativas. Adicionalmente, la latencia de establecimiento de sesión se reduce significativamente al operar sobre TCP/IP estándar frente a las sesiones CAT-TP.
Modelo de Seguridad Reforzado
El modelo de seguridad de SGP.32 incorpora mejoras sustanciales respecto a SGP.22. La autenticación mutua entre SM-DP+ y eUICC utiliza TLS 1.2 o superior con conjuntos de cifrado modernos (ECDHE para intercambio de claves, AES-128/256 para cifrado simétrico), en contraste con SCP80/SCP81 de SGP.22, que presentan vulnerabilidades conocidas ante ataques de canal lateral en implementaciones de bajo coste. Los certificados de eUICC siguen el esquema PKI definido por la GSMA CI, pero con soporte obligatorio para curvas elípticas (ECC P-256 mínimo), reduciendo el tamaño de las operaciones criptográficas respecto a RSA y mejorando la eficiencia en microcontroladores de recursos limitados.
El estándar introduce también el concepto de Profile Policy Rules con mayor granularidad operacional. En SGP.22, las políticas de perfil eran relativamente binarias (habilitar/deshabilitar/eliminar). En SGP.32, es posible definir políticas que condicionan la habilitación de un perfil a factores como la geolocalización del dispositivo (mediante datos de red), parámetros temporales, o el estado de otros perfiles coexistentes, habilitando lógicas de conmutación automática de operador con criterios complejos.
Análisis Comparativo: SGP.22 vs SGP.32
La siguiente tabla sintetiza las diferencias y similitudes técnicas más relevantes entre ambas especificaciones:
| Parámetro | SGP.22 (M2M RSP) | SGP.32 (IoT RSP) |
|---|---|---|
| Arquitectura funcional | SM-DP separado de SM-SR; acoplamiento bilateral entre entidades; el SM-SR mantiene el estado de la eUICC y la alcanzabilidad directa. | SM-DP+ unificado; entidad IPA introducida en el dispositivo o red; separación funcional más limpia entre preparación y entrega. |
| Protocolo de transporte | CAT-TP sobre BIP; dependencia de soporte de protocolo específico en la red del MNO; incompatible con conectividad IP pura. | HTTPS/TLS sobre TCP/IP estándar; compatible con cualquier pila de conectividad IP; sin dependencia de protocolos propietarios de capa inferior. |
| Modelo de iniciación de sesión | El SM-SR inicia la sesión hacia la eUICC (push); requiere alcanzabilidad directa del dispositivo, problemática tras NAT o con conectividad intermitente. | El IPA inicia consultas al SM-DS (pull/polling); el dispositivo solicita operaciones pendientes cuando dispone de conectividad; compatible con entornos NAT y LPWAN. |
| Marco de seguridad criptográfica | SCP80/SCP81 (GlobalPlatform); RSA o ECC según implementación; vulnerabilidades documentadas en implementaciones de bajo coste. | TLS 1.2+ con ECDHE/AES; ECC P-256 obligatorio; autenticación mutua reforzada; mayor resistencia a ataques de canal lateral en eUICCs de recursos reducidos. |
| Transferencia entre plataformas | Ownership Transfer entre SM-SRs requiere coordinación contractual y técnica explícita entre partes; alta fricción en entornos multiproveedor. | Arquitectura SM-DP+ estandarizada reduce dependencia de acuerdos bilaterales; interoperabilidad mejorada entre proveedores certificados por GSMA. |
| Soporte de tecnologías LPWAN/LTE-M/NB-IoT | Diseñado para dispositivos con conectividad de datos continua; inadecuado para dispositivos con ciclos de sueño prolongados o ancho de banda muy reducido. | Optimizado para dispositivos con conectividad intermitente y baja capacidad de procesamiento; el modelo de polling del IPA es inherentemente compatible con ciclos de actividad/sueño. |
| Complejidad de gestión multioperador | Requiere coordinación entre múltiples pares SM-DP/SM-SR por operador; escalado complejo en despliegues con portafolio amplio de MNOs. | Un único SM-DP+ puede gestionar perfiles de múltiples operadores; simplificación significativa de la cadena de aprovisionamiento en flotas multioperador. |
| Granularidad de políticas de perfil | Políticas básicas de habilitación/deshabilitación/eliminación; lógica de conmutación de perfil limitada. | Profile Policy Rules con condicionantes múltiples (geolocalización de red, temporales, estado de perfiles coexistentes); permite automatización avanzada de conmutación de operador. |
| Madurez y adopción en hardware | Especificación madura (publicada en 2016); amplia base instalada en dispositivos M2M legacy; soporte en chipsets históricos bien establecido. | Especificación más reciente; adopción creciente en nuevas generaciones de módulos IoT (Quectel, Sierra Wireless, Thales); soporte en hardware de nueva generación. |
Escenarios de Aplicación: Ventajas Determinantes de SGP.32
Escenario 1: Despliegue Masivo de Flotas Vehiculares con Roaming Internacional
Considérese el despliegue de unidades de telemática vehicular para una empresa de transporte de mercancías que opera en múltiples países de la Unión Europea y el norte de África. Cada vehículo incorpora una pasarela IoT con eUICC. El portafolio de conectividad requiere perfiles de operadores diferentes según el país de operación habitual, con capacidad de conmutación automática al cruzar fronteras o cuando el operador primario presenta degradación de cobertura.
Con SGP.22, la gestión de esta lógica de conmutación requeriría la coordinación de múltiples SM-SRs (uno por MNO en el portafolio), cada uno con acuerdos de interoperabilidad establecidos, y la implementación de lógica de señalización de red para detectar cambios de país y disparar operaciones de cambio de perfil a través del SM-SR correspondiente. La ventana de conmutación, sumando latencia de detección, establecimiento de sesión CAT-TP y transferencia del perfil, puede superar varios minutos, durante los cuales el dispositivo carece de conectividad operativa.
Con SGP.32, el IPA residente en la pasarela vehicular monitoriza continuamente los parámetros de red (MCC/MNC del PLMN registrado, indicador de señal, latencia de datos). Las Profile Policy Rules configuradas en el SM-DP+ definen umbrales de conmutación basados en estos parámetros. Cuando se cumplen las condiciones, el IPA consulta el SM-DS, recibe la notificación de cambio de perfil, y ejecuta la descarga e instalación sobre HTTPS. La latencia total, al operar sobre TCP/IP estándar con perfil precargado en el SM-DP+, se reduce a segundos. La centralización en un único SM-DP+ elimina la coordinación multi-SR y permite que el gestor de flota opere sobre una única plataforma de aprovisionamiento, independientemente del número de MNOs en el portafolio.
Escenario 2: Infraestructura de Medición Inteligente con NB-IoT en Entorno Urbano
Un operador de servicios públicos despliega 200.000 contadores de agua con comunicación NB-IoT. Cada contador incorpora una eUICC y transmite lecturas cada seis horas. El ancho de banda disponible es extremadamente reducido (tipicamente inferior a 250 kbps de pico), el consumo energético es crítico (el dispositivo opera con batería durante diez años), y los dispositivos están distribuidos en zonas con cobertura NB-IoT de múltiples operadores.
En SGP.22, la arquitectura de sesión SM-SR→eUICC iniciada por el servidor requiere que el dispositivo esté accesible cuando el servidor desea ejecutar una operación. Un contador NB-IoT en ciclo de bajo consumo no es alcanzable de forma persistente. La implementación de mecanismos de wake-up por SMS o señalización PSM (Power Saving Mode) para habilitar ventanas de gestión introduce complejidad de implementación significativa y dependencia de características de red que no todos los MNOs exponen uniformemente. Adicionalmente, los intercambios SCP80/SCP81 de SGP.22 generan un overhead de bytes no trivial en canales NB-IoT de ancho de banda muy reducido.
En SGP.32, el IPA del contador puede incorporarse en el microcontrolador principal del dispositivo como proceso de baja prioridad. En cada ventana de actividad programada (por ejemplo, al concluir el envío de la lectura), el IPA ejecuta una consulta ligera al SM-DS sobre HTTPS. Si no hay operaciones pendientes, la consulta consume un mínimo de recursos. Si existe una operación de aprovisionamiento, se ejecuta en la misma ventana de conectividad activa. Este modelo elimina completamente la necesidad de mecanismos de alcanzabilidad push y es naturalmente coherente con los ciclos PSM/eDRX de NB-IoT.
Escenario 3: Pasarelas Industriales en Entornos con Redundancia de Operador por SLA
Infraestructuras críticas como subestaciones eléctricas, plantas de tratamiento de agua o nodos de comunicación ferroviaria frecuentemente requieren conectividad celular con acuerdos de nivel de servicio (SLA) estrictos, incluyendo conmutación automática de operador ante caída del servicio del MNO primario con ventanas de recuperación inferiores a treinta segundos.
Con SGP.22, implementar esta redundancia mediante conmutación de perfil eSIM requiere un proceso de habilitación/deshabilitación de perfil gestionado por el SM-SR, con tiempos de respuesta incompatibles con los SLAs descritos. En la práctica, los despliegues legacy resuelven este requisito con módulos celulares dobles (una SIM física por operador), lo que duplica el coste de hardware y la superficie de gestión.
Con SGP.32, la capacidad de tener múltiples perfiles instalados en la eUICC simultáneamente, combinada con la granularidad de las Profile Policy Rules y la capacidad del IPA de conmutar perfiles en respuesta a eventos de red locales detectados en tiempo real, permite implementar lógicas de conmutación automática con latencias compatibles con los SLAs industriales. La detección de pérdida de señal del operador primario puede disparar localmente la habilitación del perfil de operador secundario sin necesidad de señalización al servidor, reduciendo la ventana de recuperación a la latencia de reregistro en la nueva red, típicamente inferior a diez segundos.
Integración en Hardware Comercial: Teltonika y Robustel en el Ecosistema SGP.32
Teltonika Networks: Convergencia de Routing Industrial y Gestión eSIM
Teltonika Networks ha incorporado soporte de eUICC en su línea de routers industriales (series RUT y TRB), con modelos específicos diseñados para operar conforme a los requisitos de arquitectura SGP.32. El hardware integra módulos celulares de nueva generación con soporte para eUICC en formato MFF2 (Machine Form Factor 2), optimizados para el perfil de temperatura industrial extendido (-40°C a +70°C) y con certificaciones relevantes para entornos de infraestructura crítica.
La plataforma RMS (Remote Management System) de Teltonika actúa como capa de orquestación por encima de la infraestructura SM-DP+. RMS no reemplaza al SM-DP+, sino que se integra con él a través de APIs para exponer las operaciones de gestión de perfiles dentro de un flujo de trabajo unificado de gestión de dispositivos. Un administrador de red puede, desde la consola RMS, visualizar el estado del perfil eSIM activo en cada dispositivo de la flota, solicitar operaciones de cambio de perfil que se encolan en el SM-DP+ correspondiente, y monitorizar el resultado de la operación de aprovisionamiento a través de los eventos de telemetría del dispositivo.
La integración RMS-SGP.32 simplifica un aspecto operacional crítico frecuentemente infravalorado: la correlación entre el estado de conectividad del dispositivo y el estado del proceso de aprovisionamiento eSIM. En despliegues SGP.22 sin plataforma de gestión unificada, un fallo en el proceso de aprovisionamiento puede manifestarse únicamente como pérdida de conectividad, sin trazabilidad del punto de fallo en la cadena SM-DP→SM-SR→eUICC. RMS, al tener visibilidad simultánea del estado de la interfaz celular, del perfil eSIM activo y de los logs del IPA, permite una diagnóstica de fallo significativamente más precisa.
Adicionalmente, la arquitectura RMS soporta operaciones de aprovisionamiento masivo (bulk provisioning) mediante la definición de perfiles de configuración de conectividad aplicables a grupos de dispositivos. Esta capacidad, combinada con el modelo de polling del IPA en SGP.32, permite que un administrador configure una operación de migración de perfil para un grupo de 5.000 dispositivos que se ejecutará progresivamente conforme cada dispositivo establece su ventana de conectividad, sin necesidad de coordinación individual o ventanas de mantenimiento sincronizadas.
Robustel: Plataforma RCMS y Gestión Avanzada del Ciclo de Vida eSIM
Robustel ha desarrollado igualmente una línea de routers y pasarelas IoT con eUICC integrada, con soporte explícito para la arquitectura SGP.32 en su gama industrial (series R2000 y R3000, entre otras). Los módulos eUICC de Robustel incorporan certificación GSMA SAS-SM (Security Accreditation Scheme for Subscription Management), garantizando que la implementación de las operaciones criptográficas definidas en SGP.32 ha superado un proceso de auditoría independiente.
La plataforma RCMS (Robustel Cloud Management System) extiende las capacidades de gestión eSIM con funcionalidades orientadas específicamente a operadores IoT y proveedores de servicios de conectividad gestionada. RCMS implementa una capa de abstracción sobre el SM-DP+ que permite gestionar simultáneamente dispositivos con perfiles de múltiples operadores desde una única interfaz, utilizando las capacidades de interoperabilidad mejorada que SGP.32 introduce respecto a SGP.22. Esta abstracción es particularmente valiosa para integradores de sistemas que despliegan flotas con conectividad de múltiples MNOs en diferentes regiones geográficas.
RCMS incorpora además capacidades de automatización de políticas de conmutación de perfil directamente alineadas con las Profile Policy Rules de SGP.32. El administrador puede definir, en la consola RCMS, reglas del tipo “si la calidad de señal del operador activo cae por debajo de -105 dBm durante más de 120 segundos, solicitar conmutación al perfil de operador secundario”. Estas reglas se traducen en configuraciones de Profile Policy Rules que RCMS propaga al SM-DP+ y, de allí, al IPA del dispositivo mediante el flujo de aprovisionamiento estándar SGP.32, sin requerir lógica de aplicación propietaria en el firmware del dispositivo.
La trazabilidad del ciclo de vida del perfil es otra área donde RCMS aporta valor diferencial. SGP.32 define eventos de auditoría obligatorios en cada operación sobre el perfil (descarga, instalación, habilitación, deshabilitación, eliminación), trazados mediante registros firmados criptográficamente. RCMS agrega y correlaciona estos eventos con los datos de telemetría del dispositivo, generando trazas de auditoría completas del ciclo de vida de cada perfil en cada dispositivo de la flota. Este nivel de trazabilidad es un requisito explícito en verticales reguladas (energía, agua, telecomunicaciones de seguridad pública) y resulta prácticamente inviable de implementar en despliegues SGP.22 sin infraestructura adicional específica.
La combinación de hardware con eUICC certificada GSMA, arquitectura de software alineada con SGP.32, y plataformas de gestión como RMS y RCMS que materializan las capacidades normativas en flujos operacionales concretos representa el estado del arte en gestión de conectividad IoT empresarial. Ambas plataformas demuestran que la transición de SGP.22 a SGP.32 no es únicamente una evolución de especificación técnica, sino una transformación del modelo operacional completo de gestión de conectividad celular en despliegues de alta escala.
Conclusión
SGP.32 supera estructuralmente a SGP.22 al resolver sus limitaciones de alcanzabilidad, eficiencia criptográfica y complejidad multioperador mediante la entidad IPA, el transporte HTTPS y el SM-DP+ unificado. Para despliegues IoT de escala industrial, SGP.32 no es una opción incremental sino un requisito funcional. Teltonika RMS y Robustel RCMS traducen esta especificación en plataformas operacionales concretas que unifican la gestión del ciclo de vida eSIM con la observabilidad de red, cerrando la brecha entre la norma GSMA y la realidad operacional de flotas de miles de dispositivos distribuidos geográficamente.
Referencias normativas: GSMA SGP.02 v4.2 (M2M Remote SIM Provisioning Architecture), GSMA SGP.32 v1.0 (eSIM IoT Remote SIM Provisioning Technical Specification), GSMA SGP.22 v2.5 (RSP Technical Specification – Consumer), GSMA SAS-SM v4.0 (Security Accreditation Scheme for Subscription Management).