Ley de Ciberresiliencia UE IoT: qué implica para MQTT

La Ley de Ciberresiliencia de la UE (Cyber Resilience Act, CRA) cambia la forma de diseñar, comercializar y mantener los productos conectados en la Unión Europea. Este artículo resume lo que la Ley de Ciberresiliencia de la UE significa para los fabricantes de IoT cuyos dispositivos se comunican por MQTT, cubriendo la seguridad por defecto, las actualizaciones, la gestión de vulnerabilidades y la documentación, y muestra qué decisiones de ingeniería en tu capa de mensajería respaldan ese trabajo. Es una visión técnica general, no asesoramiento jurídico; confirma tus obligaciones con un asesor cualificado y con el texto oficial.

Qué es la Ley de Ciberresiliencia

La CRA es un reglamento de la UE que establece requisitos horizontales de ciberseguridad para los "productos con elementos digitales", es decir, productos de hardware y software cuyo uso previsto incluye una conexión de datos con un dispositivo o una red. Entró en vigor en diciembre de 2024 y sus obligaciones se aplican por fases: las obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves se aplican desde septiembre de 2026, y la mayoría de las demás obligaciones desde diciembre de 2027.

Para los equipos de IoT, el punto importante es el ámbito de aplicación. Un sensor, gateway, electrodoméstico inteligente o controlador industrial que se conecta a una red y se comercializa en el mercado de la UE muy probablemente está incluido, junto con su firmware y los componentes de software que incorpora. Algunos sectores con normas propias, como ciertos productos médicos y de automoción, reciben un trato distinto.

Los productos se dividen en categorías. La mayoría pertenece a una categoría por defecto, en la que los fabricantes pueden evaluar la conformidad por sí mismos. Los productos clasificados como "importantes" o "críticos" se enfrentan a procedimientos de evaluación más estrictos. La categoría de tu dispositivo determina cuánta intervención de terceros se necesita.

Obligaciones principales de los fabricantes

Los requisitos esenciales del reglamento se dividen en dos grupos: propiedades del producto y procesos de gestión de vulnerabilidades. Simplificado para IoT:

Ámbito	Qué espera la CRA (simplificado)	Qué significa para un dispositivo MQTT
Seguridad por defecto	Los productos se entregan con una configuración segura, sin vulnerabilidades explotables conocidas	Sin contraseñas por defecto, TLS activado por defecto, sin topics de depuración habilitados
Control de acceso	Protección frente a accesos no autorizados mediante autenticación y gestión de identidades adecuadas	Credenciales únicas por dispositivo, sin conexiones anónimas al broker
Confidencialidad	Proteger los datos almacenados y transmitidos, por ejemplo con cifrado	MQTT sobre TLS, almacenamiento protegido de credenciales
Integridad	Proteger datos, comandos y firmware frente a modificaciones no autorizadas	Firmware firmado, comandos validados
Minimización de datos	Tratar solo los datos necesarios para la finalidad prevista	Publicar lo que necesita el caso de uso, nada más
Disponibilidad y resiliencia	Mantener las funciones esenciales, incluso en condiciones de denegación de servicio	Backoff, buffering, buen comportamiento ante los límites del broker
Limitar la superficie de ataque	Minimizar las interfaces expuestas	Sin puertos de entrada; solo MQTT saliente
Actualizaciones de seguridad	Ofrecer actualizaciones durante el periodo de soporte, idealmente automáticas y separadas de las de funcionalidad	Una vía OTA segura que funcione sobre tu conectividad
Gestión de vulnerabilidades	Identificar, documentar y corregir vulnerabilidades; política de divulgación coordinada	SBOM que cubra las librerías MQTT, un contacto de divulgación, un proceso de parches
Notificación	Notificar las vulnerabilidades explotadas activamente y los incidentes graves dentro de los plazos fijados	Un proceso interno para detectar, clasificar y notificar
Documentación	Documentación técnica, información al usuario, periodo de soporte	Documentar cómo se conecta el dispositivo y cómo lo protegen los usuarios

Seguridad por defecto en la capa MQTT

Muchos problemas históricos de IoT vinieron de configuraciones por defecto inseguras. En términos de MQTT, la orientación de la CRA se traduce en decisiones de diseño concretas:

Sin credenciales compartidas ni por defecto. Cada dispositivo recibe credenciales únicas durante la fabricación o el alta. Consulta aprovisionamiento seguro de dispositivos IoT.
TLS activado por defecto con verificación de certificados. Ningún modo "inseguro" en el firmware de producción.
Solo conexiones salientes. El dispositivo abre una conexión al broker; no escucha MQTT entrante.
Nada de brokers públicos para datos reales. Los brokers públicos de prueba son útiles en desarrollo, pero el firmware de producción debe conectarse a un broker privado y autenticado.
Topics mínimos. No publiques volcados de diagnóstico, credenciales ni datos personales innecesarios.
Manejo seguro de comandos. Valida cada comando contra una lista de permitidos antes de actuar.

Así se ve en un firmware de ESP32 con WiFiClientSecure y PubSubClient:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

// ISRG Root X1 (raíz de Let's Encrypt) en formato PEM, usada para verificar el broker
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Únicas por dispositivo, cargadas desde almacenamiento protegido en producción
extern const char* DEVICE_CLIENT_ID;  // YOUR_CLIENT_ID
extern const char* DEVICE_USERNAME;   // YOUR_USERNAME
extern const char* DEVICE_PASSWORD;   // YOUR_PASSWORD

WiFiClientSecure net;
PubSubClient mqtt(net);
unsigned long nextAttempt = 0;
unsigned long backoffMs = 1000;

void connectMqtt() {
  if (mqtt.connected() || millis() < nextAttempt) return;
  if (mqtt.connect(DEVICE_CLIENT_ID, DEVICE_USERNAME, DEVICE_PASSWORD)) {
    backoffMs = 1000;
  } else {
    nextAttempt = millis() + backoffMs + random(0, 1000);  // backoff con jitter
    backoffMs = min(backoffMs * 2, 300000UL);
  }
}

void setup() {
  WiFi.begin("YOUR_WIFI_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);
  net.setCACert(ROOT_CA);               // verifica el servidor; nunca llames a setInsecure()
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  connectMqtt();
  mqtt.loop();
}

Los detalles que importan para la seguridad por defecto están a la vista: verificación de certificados activada, credenciales que no están fijadas en el cuerpo del sketch y una estrategia de reconexión que no machaca al broker. El tutorial de MQTT con ESP32 muestra el bucle de publicación completo.

Actualizaciones y gestión de vulnerabilidades

La CRA da mucho peso a lo que ocurre después de comercializar un producto. En los dispositivos MQTT, la capa de conectividad forma parte de esa historia:

Conoce tus componentes. Mantén una lista de materiales de software (SBOM) con tu librería cliente MQTT, tu librería TLS y sus versiones. Cuando aparezca un aviso, necesitas saber en cuestión de horas qué productos usan el código afectado.
Ten un canal de actualización. Muchos equipos usan MQTT para avisar de que hay una actualización disponible y HTTPS para descargar una imagen firmada. Sea cual sea el mecanismo, debe estar autenticado y protegido en su integridad.
Separa las actualizaciones de seguridad. Siempre que sea posible, distribuye las correcciones de seguridad de forma independiente de las versiones con nuevas funciones.
Publica una política de divulgación. Ofrece a los investigadores una vía clara para notificar problemas.
Prepárate para notificar. Decide quién clasifica las vulnerabilidades e incidentes y cómo llegan las notificaciones a las autoridades dentro de los plazos exigidos.

La visión general de las vulnerabilidades MQTT más comunes es un buen punto de partida para saber qué vigilar en las librerías cliente.

Dónde encaja el broker

La CRA impone obligaciones al fabricante del producto. Elegir un broker concreto no hace que un producto cumpla la normativa, y ningún proveedor de broker puede asumir esa responsabilidad. Lo que sí puede hacer el backend es facilitar la implementación y la documentación de diseños seguros.

ConnectMQ ofrece capacidades que puedes citar en tu documentación técnica como parte de tu propia evaluación de riesgos:

MQTT sobre TLS en el 8883 y WebSockets seguros en el 8084 con un certificado de Let's Encrypt, para que los dispositivos verifiquen el servidor con una raíz estándar.
Brokers privados autenticados con credenciales generadas, y client ID vinculados a esas credenciales.
Aislamiento multi-tenant, o un clúster aislado en los planes Dedicated, o despliegue en tu propia cuenta cloud con BYOC.
Cuotas por plan señalizadas con el reason code 0x97 de MQTT 5, protección contra floods y bloqueo de IP tras varios logins fallidos, que respaldan la disponibilidad frente a abusos.
Estado de conexión mediante $SYS/broker/connection/{clientId}/state y alertas por umbral en el portal para ayudar a detectar comportamientos anómalos.

No describas ConnectMQ, ni ningún broker, como una solución de cumplimiento de la CRA. Documéntalo como un componente de tu arquitectura, enumera sus propiedades de seguridad y conserva la responsabilidad de los controles en el dispositivo. La guía de broker MQTT gestionado explica el reparto de responsabilidad compartida.

Checklist práctica de preparación para la CRA en dispositivos MQTT

Confirma si tu producto está dentro del ámbito y qué categoría le corresponde.
Realiza y documenta una evaluación de riesgos de ciberseguridad que cubra los flujos de datos MQTT.
Elimina las credenciales por defecto y compartidas; aprovisiona identidades únicas por dispositivo.
Exige TLS con verificación del certificado del servidor en el firmware de producción.
Asegúrate de que los dispositivos solo hacen conexiones salientes y no exponen interfaces innecesarias.
Valida todos los comandos recibidos y limita lo que pueden cambiar.
Implementa backoff de reconexión y buffering sin conexión para la resiliencia.
Mantén un SBOM que incluya las librerías MQTT y TLS.
Construye y prueba un mecanismo de actualización firmado y autenticado.
Publica una política de divulgación de vulnerabilidades y define el proceso de notificación.
Define y comunica el periodo de soporte.
Prepara documentación de usuario sobre la configuración segura y la retirada del servicio.

Para un contexto más amplio, buenas prácticas de seguridad MQTT y zero trust para la mensajería IoT cubren muchos de los mismos controles desde una perspectiva de ingeniería. La Comisión Europea publica la guía oficial y el texto del reglamento.

Construye una conectividad segura con ConnectMQ

Empieza por la capa de conectividad mientras avanzas con el resto de la checklist. Crea un broker privado en el plan gratuito Serverless en app.connectmq.com (sin tarjeta de crédito), apunta un dispositivo de desarrollo hacia él por TLS con credenciales únicas y usa el servidor MQTT público gratuito solo para experimentos desechables, nunca para datos de producción. Cuando necesites aislamiento, la guía de broker MQTT en la nube compara los modelos de despliegue.

Preguntas frecuentes

¿Se aplica la Ley de Ciberresiliencia a mi dispositivo IoT?

Si es un producto con elementos digitales que se conecta a un dispositivo o a una red y se comercializa en el mercado de la UE, es muy probable que sí, salvo que lo excluyan normas sectoriales. Confirma el ámbito y la categoría de tu producto con un asesor jurídico.

¿Cuándo empiezan a aplicarse las obligaciones de la CRA?

Las obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves se aplican desde septiembre de 2026, y la mayoría de las demás obligaciones desde diciembre de 2027.

¿Usar un broker MQTT seguro hace que mi producto cumpla la CRA?

No. El cumplimiento es responsabilidad del fabricante para todo el producto. Un broker seguro respalda tu diseño, pero el firmware del dispositivo, las actualizaciones, la gestión de vulnerabilidades y la documentación siguen siendo trabajo tuyo.

¿Basta MQTT sobre TLS para cumplir el requisito de confidencialidad de la CRA?

TLS protege los datos en tránsito, que es una parte importante. Aun así, debes proteger las credenciales y los datos almacenados en el dispositivo y evaluar si tu perfil de riesgo exige medidas adicionales.

Ley de Ciberresiliencia de la UE e IoT: qué implica para los dispositivos MQTT