El Cyber Resilience Act (CRA) ya no es una norma europea lejana para grandes fabricantes. El 11 de septiembre de 2026 empiezan a aplicarse sus obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves de seguridad. La aplicación principal del reglamento llegará el 11 de diciembre de 2027, pero esperar hasta entonces para organizarse es una mala estrategia.
La fecha de septiembre no significa que todo producto digital deba estar certificado de inmediato. Significa que los fabricantes de productos con elementos digitales deben poder detectar, decidir y comunicar determinados problemas de seguridad en plazos muy cortos. Si desarrollas software, distribuyes dispositivos conectados o comercializas un producto digital en la Unión Europea, conviene revisar ahora cuál es tu papel y qué procesos te faltan.
Qué es el Cyber Resilience Act
El CRA es el Reglamento (UE) 2024/2847. Su objetivo es elevar la seguridad de los productos con elementos digitales que se comercializan en la UE. Abarca hardware y software conectados o que pueden conectarse, y busca que la seguridad se tenga en cuenta desde el diseño hasta el final del periodo de soporte.
No es una extensión del RGPD ni sustituye a NIS2. El foco del CRA es el producto: cómo se diseña, actualiza, documenta, mantiene y corrige cuando aparecen vulnerabilidades. La Comisión Europea cita ejemplos tan distintos como dispositivos domésticos conectados, aplicaciones y programas informáticos; también aclara que la cadena de suministro y determinados componentes son relevantes.
Las dos fechas que debes tener claras
- 11 de septiembre de 2026: comienzan las obligaciones de reporte de vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto.
- 11 de diciembre de 2027: se aplican las obligaciones principales del CRA.
Esta diferencia es importante. En septiembre de 2026 no se activa de golpe todo el marco de requisitos, pero sí el proceso que exige reaccionar con rapidez cuando un problema serio ya está ocurriendo. Para muchas empresas, lo difícil no será rellenar una notificación: será saber con certeza qué producto está afectado, quién toma la decisión y qué evidencia se conserva.
Qué habrá que reportar y en qué plazos
La Comisión Europea establece que los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves con impacto en la seguridad de sus productos con elementos digitales. La comunicación se articula mediante la plataforma única de reporte del CRA, gestionada por ENISA y conectada con los CSIRT correspondientes.
- Alerta temprana: dentro de las 24 horas desde que se tiene conocimiento.
- Notificación completa: dentro de las 72 horas.
- Informe final: para una vulnerabilidad explotada activamente, como máximo 14 días después de disponer de una medida correctora; para un incidente grave, dentro del mes siguiente.
Estos plazos obligan a pensar en guardias, contactos alternativos, criterios de severidad y una ruta de escalado. Un buzón compartido que nadie vigila, una dependencia sin inventariar o una incidencia repartida entre soporte y desarrollo pueden hacer imposible responder a tiempo.
¿A quién afecta realmente?
El CRA se dirige principalmente a los fabricantes de productos con elementos digitales que se ponen en el mercado de la Unión Europea. También contempla responsabilidades en la cadena de suministro para importadores, distribuidores y representantes autorizados. La clasificación exacta depende de cómo se comercializa el producto, quién decide sus características y qué papel desempeña cada organización.
En términos prácticos, merece una revisión prioritaria si tu organización crea o vende aplicaciones, plugins, firmware, dispositivos IoT, equipos de red, software de escritorio, soluciones embebidas o productos digitales que se entregan a clientes. No conviene asumir que una etiqueta comercial como «SaaS», «servicio gestionado» o «open source» resuelve por sí sola el análisis de alcance: hay excepciones y matices, y cada producto debe valorarse según su situación concreta.
Lo que cambia para equipos pequeños
Una pyme no necesita copiar la estructura de una multinacional, pero sí necesita demostrar orden. La Comisión prevé medidas de apoyo para microempresas, pequeñas empresas y startups, incluyendo orientación, formación, actividades de prueba y posibles modelos simplificados de documentación técnica. Eso no elimina la responsabilidad de conocer el producto y gestionar sus vulnerabilidades.
El punto de partida razonable es convertir la seguridad del producto en una tarea de producto y operación, no en un documento que se redacta la semana antes de una auditoría. Inventario, actualizaciones, dependencias, canal de reporte y propietarios claros suelen aportar más valor inicial que comprar una herramienta aislada.
Checklist práctico para empezar ahora
- Haz inventario de productos y versiones. Identifica qué software, hardware, firmware, plugins y componentes comercializas o mantienes para clientes europeos.
- Define el rol de cada entidad. Separa fabricante, importador, distribuidor y proveedor. El nombre del contrato no siempre refleja la responsabilidad regulatoria.
- Documenta dependencias. Mantén un inventario actualizado de librerías, componentes de terceros y versiones. Sin él, saber si una vulnerabilidad te afecta será lento e impreciso.
- Establece un proceso de recepción y triaje. Debe haber un canal de divulgación de vulnerabilidades, un responsable, criterios de severidad y un contacto operativo fuera de horario cuando sea necesario.
- Prueba el ciclo de respuesta. Simula una vulnerabilidad explotada: detección, evaluación, contención, parche, comunicación y recopilación de evidencias.
- Define el periodo de soporte. El CRA exige que el fabricante indique cuánto tiempo dará soporte y gestione vulnerabilidades durante ese periodo.
- Conserva la documentación. La evaluación de riesgos, decisiones de seguridad, actualizaciones y evidencias de conformidad no deben depender de la memoria de una sola persona.
Errores que conviene evitar
- Confundir un incidente interno con una vulnerabilidad explotada activamente. No todas las incidencias son iguales, pero la clasificación debe poder justificarse y hacerse deprisa.
- Dejar el inventario en una hoja estática. Si las versiones y dependencias no se actualizan con cada entrega, el inventario deja de servir cuando llega una alerta real.
- Prometer actualizaciones sin capacidad para entregarlas. El periodo de soporte debe ser realista y tener responsables, presupuesto y proceso técnico.
- Tratarlo como un asunto exclusivamente jurídico. Legal, desarrollo, soporte, operaciones y seguridad deben compartir el mismo flujo de respuesta.
- Esperar a septiembre para probar. Los plazos de 24 y 72 horas no se improvisan cuando hay una vulnerabilidad con explotación activa.
Más allá del cumplimiento: una oportunidad para ordenar el producto
El CRA eleva la exigencia regulatoria, pero también obliga a resolver problemas que ya afectan a la confianza de clientes: software sin fecha de fin de soporte, actualizaciones poco claras, dependencias desconocidas y canales de seguridad inexistentes. Tener una respuesta ordenada mejora la capacidad de corregir fallos, reduce incertidumbre y transmite una señal de madurez a clientes y socios.
La recomendación no es prometer cumplimiento por leer una guía. Es realizar un análisis de alcance y un diagnóstico técnico-jurídico adaptado al producto y al modelo de comercialización. Si desarrollas o distribuyes productos digitales y necesitas ordenar inventario, actualizaciones, exposición y procesos de respuesta, en allado.es podemos ayudarte a plantear una hoja de ruta técnica inicial.
Este artículo es informativo y no sustituye el asesoramiento jurídico especializado para un caso concreto.
Dejar una contestacion
Lo siento, debes estar conectado para publicar un comentario.