Si fabricas un dispositivo conectado y lo vendes en la UE, la Ley de Ciberresiliencia (CRA) te aplica. Punto. No importa dónde fabriques, dónde esté registrada tu empresa ni si tienes una oficina europea.
El reglamento entró en vigor el 10 de diciembre de 2024. La mayoría de los equipos tiene el 2027 marcado como fecha límite y todavía no se ha movido. El problema es que 2027 es la fecha de aplicación final, no la única. El primer plazo firme es el 11 de septiembre de 2026, cuando entra en vigor la notificación obligatoria de vulnerabilidades. No puedes construir los procesos que exige esa notificación en un solo sprint. Los necesitas en marcha meses antes del plazo para tener la evidencia operativa que mostrar a las autoridades cuando la pidan.
Esta guía cubre lo que realmente tienes que hacer, en el orden en que hay que hacerlo.
¿Tu producto está dentro del alcance?
La CRA aplica a cualquier hardware o software que se conecte, directa o indirectamente, a un dispositivo o red, y que se comercialice en el mercado de la UE en un contexto comercial.
Tu sensor inteligente, tu gateway industrial, tu actualizador de firmware y el sistema operativo embebido de tu termostato están todos cubiertos. La prueba es sencilla: si se envía a la UE y se conecta a algo, está dentro del alcance.
Qué queda excluido:
- Productos sanitarios y vehículos de motor (cubiertos por sus propias normativas sectoriales)
- Software de código abierto no monetizado
- SaaS y PaaS puros que no sean parte integral de la función de un dispositivo dentro del alcance
- Sitios web que no den soporte al procesamiento remoto de un dispositivo dentro del alcance
Si eres importador o distribuidor en lugar del fabricante original, también tienes obligaciones. Es posible que tengas que verificar el marcado CE, conservar documentación y, en algunos casos, asumir las responsabilidades completas del fabricante si modificas el producto de forma sustancial antes de comercializarlo.
Algo más que muchos equipos pasan por alto: los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos (RED) ya aplican desde el 1 de agosto de 2025 para los equipos radioeléctricos conectados a internet. Si tu dispositivo usa Wi-Fi o Bluetooth y el plazo de agosto de 2025 ya pasó sin una evaluación RED, resuelve eso antes que cualquier otra cosa. La lista de la RED es más corta que la de la CRA, pero ya está vencida.
Paso 1: clasifica tu producto
La CRA ordena los productos en cuatro categorías de riesgo. Tu categoría determina cómo demuestras el cumplimiento.
Por defecto (cerca del 90% de todos los productos) Dispositivos conectados estándar, la mayoría del IoT de consumo, sensores industriales de menor riesgo. Se permite la autoevaluación. Evalúas tu propio producto frente a los requisitos esenciales y firmas una Declaración de Conformidad.
Importante: Clase I Productos de mayor riesgo, incluidos navegadores, gestores de contraseñas, VPN y software de gestión de redes. Se permite la autocertificación frente a una norma armonizada, o puedes recurrir a un organismo notificado.
Importante: Clase II Productos con un riesgo de seguridad significativo: firewalls industriales, sistemas de detección de intrusiones, microprocesadores, routers, módems, gateways de contadores inteligentes. En la mayoría de los casos se exige la evaluación por un tercero a cargo de un organismo notificado.
Crítico Productos de los que depende la infraestructura crítica. Requiere un esquema europeo de certificación de ciberseguridad. El reglamento de ejecución adoptado en noviembre de 2025 aclaró qué productos entran aquí.
Consulta el Anexo III y el Anexo IV del Reglamento (UE) 2024/2847 para ver las listas definitivas.
Un problema práctico con la Clase II y los productos críticos: la capacidad de los organismos notificados en la UE es limitada. Los equipos que esperen hasta finales de 2026 o hasta 2027 para empezar se encontrarán con colas. El objetivo de la Comisión Europea es tener los organismos notificados en funcionamiento para el 11 de diciembre de 2026, pero la disponibilidad puede no ajustarse a la demanda. Empieza pronto.
Paso 2: crea tu Software Bill of Materials ahora
El requisito del SBOM está en el Anexo I, Parte II de la CRA. Los fabricantes deben identificar y documentar todos los componentes de sus productos, incluido un software bill of materials en un formato de uso común y legible por máquina, que cubra como mínimo las dependencias de primer nivel.
La razón para hacerlo antes de septiembre de 2026 es operativa, no burocrática. Cuando se divulga públicamente una vulnerabilidad que se está explotando de forma activa, tienes 24 horas para notificarlo a ENISA y a tu CSIRT nacional. Para cumplir ese plazo, necesitas saber en minutos si tu producto usa el componente afectado. Sin un SBOM y un seguimiento automatizado de vulnerabilidades, pasarás esas 24 horas revisando imágenes de firmware a mano.
Lo que tu SBOM tiene que cubrir:
- Cada componente de software, desde el sistema operativo hasta los módulos de firmware
- Tanto los componentes propietarios como los de código abierto
- Números de versión e información de licencias
- Vulnerabilidades conocidas asociadas a cada componente
- Como mínimo, las dependencias de primer nivel; el seguimiento completo de dependencias transitivas cuando sea viable
La CRA todavía no exige un formato concreto, pero sí que sea “de uso común y legible por máquina”. Tanto SPDX como CycloneDX cumplen con esto. Se espera que la Comisión Europea especifique los formatos mediante actos de ejecución en 2026. Elige uno ahora e intégralo en tu pipeline de CI/CD.
No necesitas publicar tu SBOM. Las autoridades de vigilancia del mercado pueden solicitarlo, y debes poder facilitarlo con prontitud. Guárdalo en tu archivo de documentación técnica.
Para los dispositivos que reciben actualizaciones OTA, el proceso del SBOM debe mantenerse al día. Cada versión de firmware que añade o actualiza un componente requiere un SBOM actualizado antes de su lanzamiento.
Paso 3: integra la seguridad desde el principio
La mayoría de los equipos de IoT tiene más terreno por recorrer aquí. La CRA exige seguridad por diseño, no seguridad añadida justo antes de una auditoría de marcado CE.
En la fase de diseño:
- Sin contraseñas por defecto. Los dispositivos deben enviarse exigiendo que el usuario configure una credencial única, o usando credenciales únicas de hardware generadas por dispositivo.
- Minimiza la superficie de ataque. Limita las interfaces, servicios y puertos expuestos a lo que el producto realmente necesita para funcionar.
- Modelado de amenazas antes de poner en marcha el hardware, no después.
- Arranque seguro para verificar la integridad del firmware desde el encendido.
- Cifra los datos en tránsito y en reposo cuando el modelo de amenazas del producto lo justifique.
Durante el desarrollo:
- Ciclo de Vida de Desarrollo Seguro de Software (SSDL) con controles de seguridad en la revisión de código, el análisis estático y el escaneo de dependencias integrados en CI/CD.
- Ninguna vulnerabilidad crítica o de alta severidad conocida en los componentes en el momento del lanzamiento. La CRA exige que los productos se comercialicen “sin vulnerabilidades explotables conocidas”.
- Prueba frente a tu propio modelo de amenazas antes de lanzar.
Tras la comercialización:
- Las actualizaciones de seguridad deben estar disponibles para los usuarios durante al menos 5 años desde la comercialización del producto, o durante el periodo de uso previsto si es más largo.
- Una vez publicada una actualización de seguridad, debe seguir disponible durante al menos 10 años desde esa fecha de publicación, o durante el periodo de soporte restante.
- Mecanismos de actualización automática, o una notificación clara a los usuarios cuando haya actualizaciones disponibles.
- Una fecha de fin de soporte publicada para que los usuarios sepan cuándo dejarán de llegar los parches.
Paso 4: pon en marcha la gestión de vulnerabilidades y la notificación de incidentes
Este es el plazo de septiembre de 2026. A partir del 11 de septiembre de 2026, los fabricantes deben notificar a ENISA y al CSIRT nacional correspondiente en un plazo de 24 horas tras descubrir una vulnerabilidad que se esté explotando de forma activa en cualquier producto que esté actualmente en el mercado de la UE.
El calendario de notificación:
| Desencadenante | Plazo | Qué presentar |
|---|---|---|
| Vulnerabilidad explotada de forma activa descubierta | 24 horas | Aviso temprano a ENISA y al CSIRT nacional |
| Incidente de ciberseguridad grave que afecte a la seguridad del producto | 24 horas | Notificación de aviso temprano |
| Tras el aviso temprano | 72 horas | Notificación de vulnerabilidad con evaluación inicial del impacto |
| Una vez disponible la mitigación | 14 días | Informe completo: descripción, versiones afectadas, pasos de mitigación |
Esto cubre los productos heredados. Si enviaste un gateway de IoT en 2019 y sigue en el mercado de la UE el 11 de septiembre de 2026, eres responsable de notificar sus vulnerabilidades con estos plazos.
Las notificaciones van a la base de datos europea de vulnerabilidades de ENISA y al CSIRT nacional del o de los Estados miembros donde se vende el producto. Normalmente se reenvían a los CSIRT de cada Estado miembro donde se comercializa el producto.
Lo que necesitas tener en marcha antes de septiembre de 2026:
- Una política de divulgación coordinada de vulnerabilidades (CVD), publicada y localizable
- Un contacto de seguridad monitorizado y un archivo security.txt
- Flujos internos de triaje con responsabilidades claras y vías de escalado
- SBOM y seguimiento de dependencias para poder responder “¿estamos afectados?” en horas, no en días
- Una relación de trabajo con tu CSIRT nacional antes de necesitar llamarlos
Paso 5: prepara tu documentación técnica
Todo fabricante debe mantener un archivo de documentación técnica. Las autoridades de vigilancia del mercado pueden solicitarlo en cualquier momento. Los requisitos de contenido están en el Anexo VII de la CRA.
Tu archivo técnico debe incluir:
- Descripción del producto: nombre, versión, tipo, rango de números de serie
- Evaluación de riesgos: tu modelo de amenazas de ciberseguridad y cómo lo abordan tus decisiones de diseño
- Arquitectura de seguridad: cómo el producto cumple los requisitos esenciales
- SBOM
- Descripción del proceso de desarrollo seguro: estándares de codificación, proceso de revisión, metodología de pruebas
- Procedimiento de gestión de vulnerabilidades
- Resultados de pruebas y verificación
- Referencia a la Declaración de Conformidad
Conserva la documentación durante 10 años después de que el producto salga del mercado. Actualízala cuando publiques actualizaciones de seguridad.
Paso 6: acierta con el marcado CE
El marcado CE bajo la CRA no es lo mismo que el marcado CE bajo directivas anteriores. No puedes autodeclarar el cumplimiento y poner una marca CE en un producto de Clase II.
Para los productos de la categoría por defecto: se permite la autoevaluación. Completa la evaluación de conformidad, elabora una Declaración de Conformidad y aplica la marca CE.
Para los productos importantes de Clase I: autocertifica frente a una norma armonizada, o recurre a un organismo notificado.
Para los productos importantes de Clase II y críticos: en la mayoría de los casos se exige la evaluación de un organismo notificado.
Tu Declaración de Conformidad debe incluir:
- Identificación del producto (nombre, tipo, lote, número de serie)
- Nombre y dirección del fabricante
- Declaración de conformidad con el Reglamento (UE) 2024/2847
- Nombre y número del organismo notificado, si procede
- Datos del firmante autorizado
La marca CE debe figurar en el producto, en su embalaje o en la documentación que lo acompaña si el producto es demasiado pequeño para llevarla.
Lo que hace tropezar a la mayoría de los equipos
Tratarlo como una casilla que se marca una sola vez. La CRA exige procesos continuos. La monitorización de vulnerabilidades, las actualizaciones del SBOM y la notificación de incidentes se ejecutan de forma continua mientras tu producto esté en el mercado.
Ignorar los productos ya enviados. Si todavía está a la venta en la UE el 11 de septiembre de 2026, está dentro del alcance de la notificación de vulnerabilidades. Eso incluye productos de 2019.
Subestimar el alcance del SBOM. Una imagen de firmware típica contiene decenas o cientos de componentes. El inventario manual no escala. Automatiza la generación del SBOM dentro de tu pipeline de compilación desde el principio.
Pasar por alto las obligaciones de la cadena de suministro. Los componentes de terceros conllevan un riesgo que recae en ti como fabricante. Tus contratos con proveedores necesitan obligaciones de SBOM y cláusulas de divulgación de vulnerabilidades. Una vulnerabilidad en una librería que envía tu proveedor de chips sigue siendo tu responsabilidad de notificación.
Dar por hecho que las normas armonizadas llegarán a tiempo. La estandarización de CEN/CENELEC para la CRA está en curso. Para los productos que requieren evaluación de terceros, las normas pueden seguir incompletas cuando necesites certificar. Involucra a un organismo notificado pronto para acordar qué evidencia aceptarán mientras tanto.
Una nota sobre tu plataforma de IoT
Una pregunta que surge a menudo: ¿la plataforma en la nube a la que se conecta tu dispositivo afecta a tu cumplimiento de la CRA?
Si usas una plataforma de IoT de propósito general que no desarrollaste tú ni se desarrolló por encargo tuyo, no cae directamente bajo la CRA. El SaaS y el PaaS puros quedan excluidos del reglamento. Lo que importa para tu archivo técnico de la CRA es que documentes la plataforma como parte de tu cadena de suministro, entiendas los controles de seguridad que aplica y tengas evidencia que puedas presentar a las autoridades de vigilancia del mercado.
Al evaluar plataformas, busca cifrado documentado en reposo y en tránsito, controles de acceso, registro de auditoría, procesos publicados de divulgación de vulnerabilidades y validación de seguridad por terceros. La certificación ISO/IEC 27001, las puntuaciones de seguridad independientes y un portal de seguridad publicado con documentación disponible son las cosas que hay que pedir. Las plataformas que no puedan aportar esta evidencia con rapidez ralentizarán tu proceso de documentación de la CRA.
TagoIO mantiene la certificación ISO/IEC 27001, el cumplimiento del GDPR y un Portal de Seguridad público en security.tago.io con informes de auditoría, autoevaluaciones de seguridad y documentación completa disponible bajo petición. Si usas TagoIO como parte del pipeline de datos de tu dispositivo, la documentación de seguridad que necesitas para la evaluación de tu cadena de suministro está ahí.
Calendario
| Fecha | Hito |
|---|---|
| 10 de diciembre de 2024 | La CRA entró en vigor |
| 1 de agosto de 2025 | Los requisitos de ciberseguridad de la RED aplican a los equipos radioeléctricos conectados a internet |
| 11 de junio de 2026 | Las notificaciones de los organismos de evaluación de la conformidad deben estar en marcha |
| 11 de septiembre de 2026 | Comienzan las obligaciones de notificación de vulnerabilidades e incidentes |
| 11 de diciembre de 2027 | Todos los requisitos de la CRA son plenamente exigibles |
Recursos
- Reglamento (UE) 2024/2847: el texto de la CRA. Empieza por el Anexo I (requisitos de seguridad), el Anexo III/IV (categorías de productos) y el Anexo VII (documentación técnica).
- Orientaciones de ENISA sobre la CRA: enisa.europa.eu
- IoT Security Foundation: recursos de cumplimiento y mapeo de normas de ENISA en iotsecurityfoundation.org
- ETSI EN 303 645: la norma de seguridad de IoT de consumo ya existente, muy alineada con los requisitos del Anexo I de la CRA
- Orientaciones de la Comisión Europea sobre la CRA: publicadas para recibir comentarios en marzo de 2026, cubren la interpretación del alcance y el apoyo a las pymes
Este artículo refleja el estado de la CRA en abril de 2026. Los actos de ejecución y las normas armonizadas todavía se están finalizando. Consulta las páginas de estrategia digital de la Comisión Europea para ver las actualizaciones. El Reglamento (UE) 2024/2847 es la fuente autorizada.
