Cyber Resilience Act: la importancia de una conectividad IoT resiliente y segura

Para los fabricantes de dispositivos IoT, la ciberseguridad ya no se limita al momento de la instalación o puesta en marcha. El verdadero reto está en poder seguir gestionando, monitorizando y actualizando los dispositivos de forma segura durante toda su vida útil.

En este nuevo escenario regulatorio, la resiliencia de la conectividad adquiere un papel clave. Si un dispositivo pierde conectividad, la capacidad de actuar ante una vulnerabilidad, desplegar actualizaciones de seguridad o responder rápidamente ante un incidente puede verse comprometida.

Por eso, para muchos fabricantes IoT y OEMs, el riesgo ya no depende únicamente de haber desarrollado un dispositivo seguro desde el inicio, sino también de garantizar un acceso remoto estable, continuo y seguro a los equipos desplegados sobre el terreno.

En resumen, aunque el Cyber Resilience Act no regula la conectividad como una categoría independiente, sí obliga a los fabricantes a garantizar la seguridad de los dispositivos IoT durante todo su ciclo de vida. Esto incluye aspectos como la gestión de vulnerabilidades, las actualizaciones de seguridad, la disponibilidad de los dispositivos y la reducción de riesgos de exposición.

En la práctica, esto supone un reto importante para las empresas que gestionan dispositivos conectados a gran escala. Si un equipo pierde conectividad, deja de ser accesible de forma remota o permanece expuesto directamente a internet, responder ante incidencias de ciberseguridad y demostrar el cumplimiento normativo se vuelve mucho más complejo.

El Cyber Resilience Act, aprobado por la Unión Europea a finales de 2024, establece nuevos requisitos de ciberseguridad para los llamados “productos con elementos digitales”. En la práctica, esta normativa afecta a una gran parte del ecosistema IoT, incluyendo dispositivos conectados como sensores, gateways, sistemas de teleasistencia, cargadores de vehículos eléctricos, terminales de pago, contadores inteligentes y otras soluciones conectadas utilizadas en entornos críticos.

Además del propio hardware, el reglamento también pone el foco en el software y las plataformas de gestión remota que permiten monitorizar, actualizar y mantener estos dispositivos a lo largo de su ciclo de vida.

No obstante, algunos sectores regulados, como los dispositivos médicos, determinados sistemas del sector automoción, la aviación o ciertos equipos marítimos, cuentan con normativas específicas y pueden quedar fuera del alcance directo del CRA.

La aplicación del reglamento se realizará de forma progresiva, con distintos plazos previstos para su implementación en toda la Unión Europea.

Para los entornos IoT con dispositivos de larga vida útil, el plazo de adaptación del Cyber Resilience Act es más corto de lo que puede parecer a primera vista.

En el caso de los productos ya comercializados en el mercado europeo antes del 11 de diciembre de 2027, la situación es más matizada: las principales obligaciones del CRA solo se aplicarán a partir de esa fecha si dichos productos sufren modificaciones sustanciales posteriormente.

Los dispositivos que se introduzcan en el mercado una vez el reglamento esté plenamente en vigor deberán cumplir directamente con todos los requisitos del CRA. Sin embargo, las obligaciones de notificación de vulnerabilidades también afectan a los productos ya existentes dentro del alcance normativo antes de esa fecha, lo que introduce una capa adicional de complejidad para los fabricantes.

En términos prácticos, el cumplimiento del CRA para fabricantes IoT se estructura en tres grandes pilares:

Seguridad desde el diseño

Los productos deben cumplir los requisitos esenciales de ciberseguridad establecidos en el reglamento, basados en una evaluación de riesgos documentada. Esto incluye configuraciones seguras por defecto, protección de la confidencialidad e integridad de los datos y la reducción de superficies de ataque desde el diseño.

Gestión de vulnerabilidades durante todo el ciclo de vida

Los fabricantes deben ser capaces de identificar, documentar y corregir vulnerabilidades durante todo el periodo en el que el producto esté en uso.

Esto implica:

• Proporcionar actualizaciones de seguridad sin coste adicional.
• Habilitar actualizaciones automáticas por defecto cuando sea posible.
• Ofrecer información clara al usuario sobre el soporte del producto.
• Mantener documentación completa de componentes (incluyendo SBOM o lista de materiales de software).
• Garantizar un periodo de soporte mínimo de cinco años, ampliable en función de la vida útil real del dispositivo.

Una vez definido, este periodo de soporte pasa a formar parte del compromiso comercial del fabricante.

Evaluación de conformidad y marcado CE

Para los productos IoT incluidos en el alcance del CRA, el acceso al mercado europeo dependerá de la evaluación de conformidad y del marcado CE.

El nivel de exigencia varía según la categoría del producto:

• Productos estándar: normalmente autoevaluación del fabricante.
• Clase importante I: (por ejemplo, routers, cámaras de seguridad o cerraduras inteligentes) pueden optar a autoevaluación si cumplen normas armonizadas o esquemas de certificación; en caso contrario, se requiere evaluación externa.
• Clase importante II: (como sistemas de detección de intrusiones o firewalls) requieren evaluación por terceros o certificación aplicable.
• Productos críticos: (como módulos de seguridad o gateways de contadores inteligentes) requieren evaluación externa o esquemas de certificación europeos específicos cuando estén disponibles.

Obligaciones de reporte de incidentes

El CRA también introduce plazos estrictos de notificación para vulnerabilidades explotadas e incidentes de seguridad graves:

• Notificación inicial en un máximo de 24 horas.
• Informe ampliado en 72 horas.
• Informe final entre 14 días y un mes, dependiendo del tipo de incidente y de las medidas correctivas.

Este sistema introduce una presión operativa importante sobre los fabricantes, que deben disponer de procesos de respuesta rápida y conectividad fiable para poder cumplir los plazos.

Aunque el Cyber Resilience Act es una normativa centrada en ciberseguridad, uno de los aspectos más relevantes y, a menudo menos evidentes, es que la disponibilidad del producto también forma parte de los requisitos de diseño recogidos en el reglamento.

En la práctica, los dispositivos IoT deben estar diseñados para garantizar que sus funciones esenciales sigan operativas incluso después de un incidente de seguridad. Además, deben minimizar cualquier impacto que puedan tener sobre la disponibilidad de otros sistemas, redes o dispositivos con los que interactúan.

Esto no debe interpretarse como una obligación de garantizar un nivel de “uptime” o disponibilidad continua, sino como un requisito de seguridad del producto que debe contemplarse desde la fase de diseño, demostrarse mediante análisis de riesgo y mantenerse a lo largo del ciclo de vida del dispositivo.

Impacto directo en dispositivos IoT celulares

En el caso del IoT celular, esta exigencia tiene implicaciones muy concretas. Si un fabricante pierde la capacidad de comunicarse con un dispositivo desplegado en campo, puede encontrarse con limitaciones importantes para:

• Desplegar actualizaciones de seguridad, incluidas actualizaciones automáticas cuando proceda.
• Recopilar datos de telemetría necesarios para detectar vulnerabilidades activas.
• Garantizar el funcionamiento de la función esencial para la que el dispositivo fue diseñado.

Un reto clave para el cumplimiento del CRA

El plazo de notificación de incidentes comienza en el momento en que el fabricante detecta una vulnerabilidad explotada o un incidente grave. Sin embargo, la pérdida prolongada de conectividad con los dispositivos puede dificultar la recopilación de evidencias, la investigación del incidente y el cumplimiento de los plazos regulatorios.

Por ello, la pérdida de conectividad deja de ser únicamente un problema de calidad de servicio y pasa a tener implicaciones directas en ciberseguridad, cumplimiento normativo y disponibilidad de funciones críticas.

En este contexto, la resiliencia de la conectividad no garantiza por sí sola el cumplimiento del CRA, pero sí puede formar parte de la evidencia técnica y operativa que demuestra cómo el fabricante mantiene actualizaciones, disponibilidad e incident response en entornos reales de despliegue.

En muchos despliegues de IoT celular, los dispositivos siguen dependiendo de un único operador principal, una única ruta de red core o una arquitectura de roaming comercial centralizada, incluso cuando se utilizan tarjetas SIM “multi-red” o con capacidad de itinerancia.

El problema es que, aunque exista cobertura de radio por parte de redes asociadas, si la conectividad depende del núcleo del operador principal, una caída en esa infraestructura puede dejar fuera de servicio todo el parque de dispositivos.

Este modelo funciona correctamente en condiciones normales. Sin embargo, deja de ser suficiente en escenarios como:

• Caídas del núcleo de red del operador principal en la zona de despliegue.
• Fallos localizados de red que no son cubiertos por redes de roaming.
• Cambios en acuerdos de itinerancia entre operadores.
• Apagados progresivos de redes 2G y 3G que eliminan rutas de respaldo utilizadas por dispositivos más antiguos.

Cuando la conectividad deja de ser solo un problema técnico

Imaginemos un escenario crítico: una vulnerabilidad está siendo explotada activamente y, en cuanto el fabricante la detecta, se activa la obligación de notificación en 24 horas.

Sin embargo, parte del parque de dispositivos no es accesible porque la red principal está degradada o fuera de servicio. En ese momento, el problema deja de ser únicamente de conectividad y pasa a afectar directamente a la investigación del incidente, la recopilación de evidencias y la capacidad de respuesta del fabricante.

Impacto para fabricantes OEM

Para un fabricante IoT, depender de una única red concentra un nivel significativo de riesgo en un solo proveedor de conectividad. El dispositivo puede haber sido diseñado de forma segura, estar correctamente parcheado y contar con documentación completa como un SBOM actualizado, y aun así quedar inaccesible durante una degradación o caída de red.

Desde la perspectiva del Cyber Resilience Act, esta situación impacta directamente en tres áreas clave:

• La disponibilidad del servicio.
• La capacidad de actualización remota.
• El cumplimiento de los plazos de notificación de incidentes.

El Cyber Resilience Act no impone un modelo concreto de arquitectura de conectividad. Por ejemplo, no exige que los dispositivos IoT celulares utilicen tarjetas SIM multi-red o configuraciones específicas de roaming.

Sin embargo, sí establece obligaciones claras para los fabricantes: garantizar la seguridad del producto durante toda su vida útil, gestionar vulnerabilidades, proporcionar actualizaciones de seguridad y proteger las funciones esenciales del dispositivo.

En el caso de dispositivos conectados desplegados en campo, estas responsabilidades son mucho más fáciles de cumplir y demostrar cuando el fabricante puede mantener el acceso al equipo en el momento en que es necesario.

La conectividad como parte de la preparación para el CRA

Bajo esta perspectiva, la resiliencia de la conectividad se entiende como un elemento clave en la preparación para el cumplimiento del CRA. No se trata de un requisito normativo en sí mismo, sino de un factor operativo que forma parte de la evidencia que permite demostrar que el fabricante cumple con las obligaciones establecidas por la regulación.

La tecnología patentada rSIM de CSL ofrece una respuesta directa al reto de la resiliencia de la conectividad en entornos IoT desde el propio nivel de la SIM.

A diferencia de una SIM tradicional, rSIM integra dos perfiles de operador y es capaz de monitorizar de forma autónoma el estado de la red. Cuando detecta que la conexión principal deja de ofrecer el rendimiento adecuado, cambia automáticamente al perfil de respaldo. Y cuando la red principal se recupera, vuelve a conectarse de forma automática, sin necesidad de intervención del dispositivo ni lógica adicional en el firmware.

Impacto en el cumplimiento del Cyber Resilience Act

Desde la perspectiva del Cyber Resilience Act, este comportamiento tiene implicaciones directas: reduce los periodos de inactividad, mejora la tasa de entrega de actualizaciones de seguridad en toda la flota de dispositivos y facilita la demostración de conformidad cuando un evaluador analiza cómo se garantiza la disponibilidad de las funciones esenciales.

Ventajas de rSIM en el diseño de dispositivos IoT bajo el CRA

Para los fabricantes IoT que están adaptando sus productos al nuevo marco regulatorio, hay cuatro aspectos especialmente relevantes:

• Sin rediseños de hardware

rSIM funciona con dispositivos compatibles con SIM UICC o eUICC, sin necesidad de arquitecturas dual-SIM, cambios de hardware ni módulos adicionales complejos.

• Menos complejidad en firmware y documentación

La lógica de resiliencia no reside en el dispositivo, sino en la propia SIM. Esto simplifica el firmware del fabricante, reduce dependencias y facilita la gestión de la documentación técnica y del SBOM.

• Tecnología probada en entornos críticos

rSIM está alineada con los estándares GSMA y se utiliza en despliegues IoT de alta criticidad como teleasistencia, recarga de vehículos eléctricos, retail, dispositivos para trabajadores en solitario, videovigilancia o automoción, donde las caídas de servicio tienen un impacto directo.

• Integración sin rediseño del producto

Para los OEM, la resiliencia de conectividad puede incorporarse en fases de compra y provisión, sin necesidad de rediseñar el producto.

Esto es especialmente relevante en un contexto donde los fabricantes ya están adaptándose simultáneamente al apagado de redes 2G y 3G, a la transición hacia eSIM (incluyendo GSMA SGP.32 para IoT) y a los requisitos del Cyber Resilience Act.

El Anexo I del Cyber Resilience Act no se limita a exigir disponibilidad. También establece requisitos más amplios relacionados con la ciberseguridad de los dispositivos, como la reducción de la superficie de ataque, el control de interfaces expuestas, la protección de la confidencialidad e integridad de los datos en tránsito y la gestión del acceso a los equipos.

En el caso del IoT celular, la forma en la que un dispositivo accede a Internet, o incluso si debe hacerlo directamente, es un elemento clave dentro de estos requisitos.

APN público: simplicidad a cambio de mayor exposición

Un APN público permite que el dispositivo tenga una salida directa a Internet. Esto simplifica la arquitectura y la operativa, pero también puede aumentar la dependencia de los controles de seguridad implementados en el propio firmware del dispositivo para evitar accesos no autorizados.

En un proceso de evaluación de conformidad bajo el CRA, esta dependencia exclusiva del dispositivo puede suponer una carga significativa en términos de seguridad y verificación.

APN privado: control y aislamiento de la conectividad

Un APN privado, correctamente configurado, permite enrutar el tráfico del dispositivo a través de una red móvil dedicada hacia el entorno seguro del fabricante o del cliente, sin exposición directa a Internet público.

Combinado con el uso de VPN, este enfoque aporta ventajas claras desde el punto de vista de ciberseguridad IoT:

• Reducción de la superficie de ataque, al no ser los dispositivos accesibles directamente desde Internet
• Cifrado del tráfico entre puntos de red definidos, reforzando la confidencialidad e integridad de los datos
• Control de acceso a nivel de SIM y red, como capa adicional a la seguridad del dispositivo
• Segmentación clara del tráfico, lo que facilita la monitorización, el registro y el análisis de incidentes

Implicaciones para fabricantes IoT bajo el CRA

Para los fabricantes OEM, este tipo de arquitectura permite trasladar parte de los controles de seguridad desde el firmware del dispositivo hacia la capa de conectividad gestionada, que puede administrarse de forma centralizada en todo el parque de dispositivos.

Esto tiene un impacto directo en el cumplimiento del Cyber Resilience Act, ya que puede reducir la complejidad del software embebido y, en consecuencia:

• Disminuir la superficie de software expuesta y documentada en el SBOM.
• Reducir el número de vulnerabilidades potenciales a gestionar durante el ciclo de vida del producto.
• Simplificar el mantenimiento de medidas correctivas en el tiempo.
• Reforzar la narrativa de cumplimiento en auditorías y evaluaciones de conformidad.

En la práctica, cuando un evaluador analiza cómo se protege la confidencialidad de los datos o cómo se limita la exposición del dispositivo, una arquitectura basada en APN privado y VPN ofrece una evidencia más sólida y estructurada que un conjunto de mitigaciones implementadas únicamente a nivel de firmware.

Ni rSIM ni una APN privada son, por sí mismas, soluciones de cumplimiento del Cyber Resilience Act. No generan SBOM, no gestionan programas de divulgación de vulnerabilidades, no realizan evaluaciones de conformidad ni asumen las obligaciones de notificación de incidentes en nombre del fabricante. Todas esas responsabilidades siguen recayendo directamente en el fabricante.

Lo que sí hacen estas tecnologías es reforzar la capa de conectividad sobre la que se apoyan varios de los requisitos del Anexo I del CRA. rSIM ayuda a evitar la pérdida de conectividad asociada a la dependencia de una única red. Por su parte, las APN privadas y las VPN reducen la superficie de ataque expuesta por el dispositivo y protegen los datos durante su transmisión.

En la práctica, un fabricante solo puede aplicar actualizaciones de seguridad, monitorizar el comportamiento del dispositivo y cumplir con los plazos de notificación si el equipo es accesible. Y, en un escenario ideal, esa accesibilidad debería estar siempre bajo condiciones controladas por el propio fabricante.

Durante este año, merece la pena trabajar una serie de cuestiones clave dentro de los equipos de ingeniería, producto y compras. Estas preguntas pueden servir como punto de partida para alinear a toda la organización:

Checklist de preparación CRA para fabricantes IoT

• ¿Qué productos están dentro del alcance del CRA y cuáles se consideran “importantes” o “críticos”?
• ¿Tenemos visibilidad y capacidad de acceso sobre todas las unidades desplegadas en campo, independientemente de la red utilizada?
• ¿El riesgo de dependencia de una única red está identificado y gestionado dentro de los procesos de producto y procurement?
• ¿Podría una arquitectura basada en APN privado o VPN reducir la superficie de ataque expuesta?
• ¿Qué parte de la complejidad de seguridad puede asumir la SIM o la capa de conectividad para simplificar el firmware del dispositivo?

De la teoría a la estrategia de cumplimiento

Para la mayoría de fabricantes, la respuesta a estas preguntas no será inmediata, sino parte de un proceso progresivo de adaptación. El objetivo es incorporar los requisitos del Cyber Resilience Act desde la fase de diseño del producto y reflejarlos también en los contratos con proveedores.

El periodo previo a diciembre de 2027 representa una oportunidad clave para rediseñar aquellas áreas del portfolio que presentan mayor riesgo, especialmente en lo relativo a conectividad, actualización remota y exposición a red.

En este contexto, la resiliencia de la conectividad no debe tratarse como un elemento secundario añadido al final del desarrollo, sino como parte esencial del modelo de disponibilidad y ciberseguridad que exige el CRA.

¿El Cyber Resilience Act exige conectividad multi-red en dispositivos IoT?

No. El Cyber Resilience Act no impone ninguna arquitectura concreta de conectividad. Sin embargo, sí exige que los fabricantes garanticen la disponibilidad de las funciones esenciales, la entrega de actualizaciones de seguridad y el cumplimiento de los plazos de notificación de incidentes durante todo el ciclo de vida del producto.

Estas obligaciones son mucho más fáciles de cumplir y demostrar cuando los dispositivos pueden ser accesibles de forma fiable en campo.

¿El CRA exige que los dispositivos IoT estén siempre accesibles?

No. La normativa no establece un requisito explícito de disponibilidad continua ni de nivel de “uptime”.

Lo que sí exige es que los fabricantes puedan desplegar actualizaciones de seguridad, investigar y corregir vulnerabilidades activas y cumplir con los plazos de notificación durante todo el periodo de soporte.

Si los dispositivos no son accesibles de forma prolongada, aunque no exista una obligación directa de conectividad permanente, se dificulta el cumplimiento efectivo de estas responsabilidades.

¿Una APN privada hace que un producto IoT cumpla el CRA?

No. Una APN privada no es una solución de cumplimiento por sí misma.

Sí puede contribuir a reducir la superficie de ataque del dispositivo y, combinada con VPN o cifrado a nivel de aplicación, mejorar la protección de los datos en tránsito entre puntos de red definidos.

Pero el cumplimiento del Cyber Resilience Act también incluye otros elementos obligatorios como:

• Diseño seguro del producto (secure by design).
• Gestión de vulnerabilidades.
• SBOM (lista de materiales de software).
• Evaluación de conformidad.
• Un compromiso de soporte durante el ciclo de vida.

Todas estas responsabilidades siguen recayendo en el fabricante.

¿Cuándo empiezan las obligaciones de notificación del CRA?

Las obligaciones de notificación comienzan el 11 de septiembre de 2026.

A partir de esa fecha, los fabricantes deberán:

• Notificar en un máximo de 24 horas desde la detección de una vulnerabilidad explotada o incidente grave.
• Enviar un informe ampliado en 72 horas.
• Presentar un informe final en los plazos establecidos por el artículo 14.

¿Qué deben revisar los fabricantes IoT antes de diciembre de 2027?

Antes de la aplicación completa del reglamento, los fabricantes deberían revisar:

• Qué productos entran dentro del alcance del CRA y su nivel de criticidad.
• Los procesos de gestión de vulnerabilidades.
• Los compromisos de soporte y ciclo de vida del producto.
• Las rutas de evaluación de conformidad y marcado CE.
• La arquitectura de conectividad que soporta la actualización y disponibilidad de los dispositivos en campo.

Para los fabricantes IoT, esto implica un cambio de enfoque importante: la ciberseguridad, la gestión del ciclo de vida del producto y la conectividad ya no deben abordarse como tres áreas independientes, sino como una única cuestión de diseño del producto.

Un dispositivo puede estar diseñado de forma segura desde el inicio, pero si no es accesible en campo o, por el contrario, está expuesto innecesariamente a Internet, la capacidad del fabricante para demostrar seguridad durante todo su ciclo de vida y disponibilidad conforme al Cyber Resilience Act puede verse comprometida.

En este contexto, la tecnología SIM resiliente de CSL ayuda a reducir uno de los puntos de fallo más habituales en IoT celular: la dependencia de una única red o núcleo de operador. A su vez, las soluciones de APN privado gestionado y VPN contribuyen a reducir la superficie de ataque del dispositivo desde el momento de su despliegue.

En muchos casos, estas capacidades pueden incorporarse sin necesidad de rediseñar el hardware y con cambios mínimos en el dispositivo, lo que permite a los fabricantes centrar sus esfuerzos en los aspectos realmente críticos del CRA: el desarrollo seguro, la gestión de vulnerabilidades y un compromiso sólido de soporte durante todo el ciclo de vida del producto.

CSL lleva más de tres décadas desarrollando soluciones de conectividad resiliente para dispositivos IoT en entornos críticos de vida, misión y negocio. Actualmente, la compañía da soporte a más de 3,5 millones de conexiones activas en Reino Unido, Europa y otros mercados, y cuenta con certificaciones y marcos de seguridad como Cyber Essentials Plus, ISO 27001 y una política activa de divulgación de vulnerabilidades.

Si estás analizando el impacto del Cyber Resilience Act en tus productos IoT celulares, podemos ayudarte a evaluar de forma práctica cómo encajan tecnologías como rSIM, las APN privadas, las VPN y los servicios de conectividad gestionada, sin necesidad de rediseñar la arquitectura de hardware existente.

• Reglamento (UE) 2024/2847 (la Ley de Ciberresiliencia), texto completo en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
• Reglamento de Ejecución (UE) 2025/2392 de la Comisión sobre la descripción técnica de las categorías de productos importantes y críticos: https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj
• Reglamento Delegado (UE) 2026/881 de la Comisión sobre los motivos relacionados con la ciberseguridad para retrasar la difusión de notificaciones: https://eur-lex.europa.eu/eli/reg_del/2026/881/oj
• Comisión Europea, visión general de la Ley de Ciberresiliencia: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• Comisión Europea, cronograma de implementación y recursos de la CRA (incluidas las preguntas frecuentes de la Comisión sobre la CRA y el borrador de orientación para pymes): https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
• Comisión Europea, evaluación de conformidad de la CRA: https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment
• Comisión Europea, obligaciones de notificación de la CRA: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, recursos sobre la Ley de Ciberresiliencia: https://www.enisa.europa.eu/topics/cyber-resilience-act
• ENISA, Plataforma Única de Notificación (SRP): https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
• Página del producto CSL rSIM: https://www.csl-group.com/solutions/rsim/