En resumen
Desde el 11 de septiembre de 2026 los fabricantes notifican vulnerabilidades explotadas activamente e incidentes graves en la plataforma única de ENISA.
La alerta temprana se envía en 24 horas, la notificación en 72 horas y después el informe final.
La obligación de notificación también afecta a los productos ya comercializados antes de 2027.
Desde el 11 de diciembre de 2027 se aplica todo el reglamento: evaluación de riesgos, periodo de soporte, SBOM, documentación técnica y marcado CE.
En Italia, el proyecto de decreto que designa a la ACN como autoridad de vigilancia del mercado sigue en tramitación.
Desde el 11 de septiembre de 2026, los fabricantes de software y de productos con elementos digitales que se venden en la Unión Europea deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afectan a sus productos. Lo establece el artículo 14 del Cyber Resilience Act, el Reglamento (UE) 2024/2847, y ese mismo día ENISA puso en marcha la plataforma única de notificación. El resto del reglamento se aplica desde el 11 de diciembre de 2027.
Mientras tanto, el 27 de julio de 2026 la Comisión Europea publicó sus primeras directrices de aplicación del reglamento. En Italia, el Consejo de Ministros aprobó el 2 de octubre de 2026, en examen preliminar, el proyecto de decreto legislativo que designa a la Agencia para la Ciberseguridad Nacional (ACN) como autoridad de vigilancia del mercado. En esta guía encontrarás lo que exige hoy la norma, a quién afecta y una lista de control para llegar preparado a 2027. No es asesoramiento jurídico: si tienes dudas sobre tu caso, compruébalo con un abogado o un consultor con experiencia.
¿Qué cambió el 11 de septiembre de 2026 con el Cyber Resilience Act?
Pasó a ser aplicable la obligación de notificación de los fabricantes. El artículo 71 del reglamento fija la plena aplicación el 11 de diciembre de 2027, pero adelanta el artículo 14 al 11 de septiembre de 2026. Desde entonces, si un fabricante tiene conocimiento de una vulnerabilidad explotada activamente o de un incidente grave que afecta a la seguridad de su producto, debe notificarlo en plazos concretos.
Vulnerabilidad explotada activamente e incidente grave: qué significan
El reglamento no exige notificar cualquier defecto. Una vulnerabilidad explotada activamente es aquella para la que existen pruebas fiables de que un agente malintencionado la ha explotado en un sistema sin permiso de su propietario (art. 3, punto 42). Una vulnerabilidad detectada en una prueba interna y nunca explotada no entra en esta obligación, aunque igualmente hay que gestionarla.
Un incidente que afecta a la seguridad del producto se considera grave si afecta, o puede afectar, a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes. También es grave si ha provocado, o puede provocar, la ejecución de código malicioso en el producto o en los sistemas de un usuario (art. 14, apartado 5).
La obligación también afecta a los productos ya vendidos
Es el punto que más sorprende. Por regla general, los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos al reglamento si sufren una modificación sustancial. Sin embargo, el artículo 69, apartado 3, establece una excepción: las obligaciones de notificación del artículo 14 se aplican a todos los productos incluidos en el ámbito del reglamento, también a los que ya están en el mercado. Si llevas años vendiendo un producto conectado, la obligación también le afecta.
Cómo funciona la notificación: plazos, destinatarios y plataforma única
Las notificaciones se envían de forma simultánea al CSIRT designado como coordinador y a ENISA, la Agencia de la Unión Europea para la Ciberseguridad. No se envían por correo electrónico: pasan por la plataforma única de notificación prevista en el artículo 16 y gestionada por ENISA.
Los plazos del artículo 14
El reglamento prevé tres pasos sucesivos, con plazos distintos para vulnerabilidades e incidentes. Los plazos empiezan a contar desde que el fabricante tiene conocimiento del hecho.
Paso | Vulnerabilidad explotada activamente | Incidente grave |
|---|---|---|
Alerta temprana | sin demora indebida y, en cualquier caso, en 24 horas | sin demora indebida y, en cualquier caso, en 24 horas, indicando si se sospecha de un acto ilícito o malicioso |
Notificación | en 72 horas, con información general sobre el producto, la naturaleza de la explotación y las medidas correctoras o paliativas | en 72 horas, con la naturaleza del incidente, una evaluación inicial y las medidas adoptadas |
Informe final | en 14 días desde que hay disponible una medida correctora o paliativa | en un mes desde la notificación del incidente |
En la alerta temprana, el fabricante indica, cuando proceda, los Estados miembros en los que sabe que el producto se ha comercializado. El CSIRT que recibe primero la notificación puede pedir también un informe intermedio. El reglamento prevé además la notificación voluntaria (art. 15) de vulnerabilidades no explotadas, amenazas y cuasiincidentes.
A qué CSIRT va la notificación
La notificación se envía a través del punto de acceso del CSIRT designado como coordinador del Estado en el que el fabricante tiene su establecimiento principal en la Unión, es decir, donde se toman principalmente las decisiones sobre la ciberseguridad de sus productos (art. 14, apartado 7). Para un fabricante con centro de decisión en Italia, la lista de ENISA de CSIRT designados como coordinadores según el reglamento remite al CSIRT Italia de la ACN. Si tu establecimiento principal está en España, consulta en esa misma lista el CSIRT que corresponde.
ENISA lanzó la plataforma el 11 de septiembre de 2026 y ha publicado preguntas frecuentes, manuales de uso y guías de registro. Según la página de la Agencia, el 4 de noviembre de 2026 la plataforma se actualizó a la versión 1.3: conviene registrarse con antelación, antes de necesitarla, y revisar periódicamente la documentación actualizada.
Informar a los usuarios
Notificar a las autoridades no basta. Cuando tiene conocimiento de una vulnerabilidad explotada activamente o de un incidente grave, el fabricante informa a los usuarios afectados y, si es necesario, indica las medidas que pueden adoptar para mitigar el impacto (art. 14, apartado 8). Si el fabricante no lo hace a tiempo, el CSIRT puede informar directamente a los usuarios.
¿A quién afecta el Cyber Resilience Act?
El reglamento se aplica a los productos con elementos digitales comercializados cuya finalidad prevista o uso razonablemente previsible incluye una conexión de datos, directa o indirecta, a un dispositivo o a una red (art. 2). La definición abarca productos de software y hardware, sus componentes introducidos en el mercado por separado y sus soluciones de tratamiento de datos a distancia.
Fabricantes
Es fabricante quien desarrolla o fabrica un producto con elementos digitales, o lo encarga, y lo comercializa con su propio nombre o marca, a título oneroso, de monetización o gratuito (art. 3, punto 13). Las obligaciones de notificación del artículo 14 se aplican a los fabricantes.
Atención también a los artículos 21 y 22: un importador o distribuidor que introduce en el mercado un producto con su propia marca, o cualquiera que haga una modificación sustancial de un producto ya comercializado y lo ponga a disposición, se considera fabricante y asume las mismas obligaciones.
Importadores y distribuidores
Los importadores introducen en el mercado solo productos conformes: antes verifican la evaluación de la conformidad, la documentación técnica, el marcado CE y las instrucciones (art. 19). Los distribuidores verifican el marcado CE y la documentación recibida (art. 20). Ambos, cuando tienen conocimiento de una vulnerabilidad, informan al fabricante sin demora indebida.
Administradores de software de código abierto
El reglamento introduce la figura del administrador de software de código abierto (en inglés, open-source software steward): una persona jurídica, distinta del fabricante, que presta un apoyo sistemático y continuado al desarrollo de software libre y de código abierto destinado a actividades comerciales (art. 3, punto 14). Tiene obligaciones más ligeras: una política de ciberseguridad documentada y la cooperación con las autoridades (art. 24). Según ENISA, las obligaciones de notificación de los administradores se aplican desde el 11 de diciembre de 2027.
Productos importantes y críticos
El anexo III del reglamento enumera los productos importantes, divididos en dos clases. En la clase I figuran, por ejemplo, sistemas operativos, navegadores, gestores de contraseñas, VPN, routers, sistemas SIEM y productos de hogar inteligente con funciones de seguridad. En la clase II figuran, por ejemplo, cortafuegos, sistemas de detección y prevención de intrusiones e hipervisores. El anexo IV enumera los productos críticos, como tarjetas inteligentes y elementos seguros. En noviembre de 2025 la Comisión adoptó un acto de ejecución con las descripciones técnicas de estas categorías.
La clasificación importa para la evaluación de la conformidad: para los productos que no son ni importantes ni críticos, el fabricante puede elegir también el procedimiento de control interno, mientras que para los productos importantes y críticos el reglamento prevé procedimientos más exigentes (arts. 7, 8 y 32). Algunos productos quedan excluidos porque los regulan otras normas, como los productos sanitarios.
¿Qué cambia a partir del 11 de diciembre de 2027?
Desde esa fecha se aplica todo el reglamento. Un producto con elementos digitales solo puede comercializarse si cumple los requisitos esenciales de ciberseguridad del anexo I y si los procesos del fabricante cumplen los requisitos de gestión de vulnerabilidades (art. 6).
Las principales obligaciones del fabricante
El artículo 13 exige al fabricante realizar una evaluación de riesgos de ciberseguridad, documentarla y tenerla en cuenta en todas las fases, desde el diseño hasta el mantenimiento. También debe actuar con la diligencia debida con los componentes de terceros, incluidos los de código abierto.
Además, el fabricante debe fijar un periodo de soporte, durante el cual gestiona las vulnerabilidades del producto. El periodo refleja el tiempo de uso previsto y es de al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo: en ese caso coincide con el tiempo de uso previsto. Cada actualización de seguridad sigue disponible al menos diez años desde su publicación o durante el resto del periodo de soporte, si es más largo. La fecha de fin del periodo de soporte debe indicarse con claridad en el momento de la compra.
Gestión de vulnerabilidades y lista de materiales de software
El anexo I, parte II, enumera los requisitos de gestión de vulnerabilidades. El fabricante identifica y documenta las vulnerabilidades y los componentes del producto, también elaborando una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina que incluya al menos las dependencias de primer nivel. Además, debe corregir sin demora las vulnerabilidades, probar periódicamente la seguridad, adoptar una política de divulgación coordinada de vulnerabilidades, facilitar una dirección de contacto para las notificaciones y distribuir las actualizaciones de forma segura y gratuita.
Documentación técnica y marcado CE
Antes de introducir el producto en el mercado, el fabricante elabora la documentación técnica (art. 31 y anexo VII): descripción del producto, arquitectura, procesos de gestión de vulnerabilidades, evaluación de riesgos, información usada para fijar el periodo de soporte, normas aplicadas e informes de ensayo. Después sigue el procedimiento de evaluación de la conformidad, redacta la declaración UE de conformidad y coloca el marcado CE. La documentación y la declaración se conservan al menos diez años o durante el periodo de soporte, si es más largo.
¿Qué dicen las directrices de la Comisión de julio de 2026?
El 27 de julio de 2026 la Comisión publicó sus primeras directrices de aplicación del Cyber Resilience Act (documento C(2026) 5252). La Comisión las describe como no vinculantes, pero útiles para prepararse desde ya.
Según la página oficial, el documento aclara el ámbito de aplicación, con especial atención a las soluciones de tratamiento de datos a distancia y al software libre y de código abierto. También aborda el concepto de modificación sustancial, los periodos de soporte, las obligaciones de notificación y la evaluación de riesgos. Para microempresas y pymes incluye 67 ejemplos, casos de uso, diagramas de flujo y gráficos. La Comisión mantiene además actualizado un documento de preguntas frecuentes sobre la aplicación.
Si tu producto está en el límite del ámbito de aplicación, por ejemplo un software con un componente en la nube o un dispositivo que recibe actualizaciones, las directrices son el primer documento que debes leer después del texto del reglamento.
¿En qué punto está el decreto italiano sobre el Cyber Resilience Act?
El reglamento es directamente aplicable, pero cada Estado miembro debe designar sus autoridades de vigilancia del mercado (art. 52) y fijar las normas sobre sanciones. En Italia, el Consejo de Ministros n.º 191 del 2 de octubre de 2026 aprobó, en examen preliminar, el decreto legislativo de adaptación de la normativa nacional al reglamento.
Según el comunicado del Gobierno italiano, el proyecto de decreto designa a la ACN como autoridad de notificación de los organismos de evaluación de la conformidad y de vigilancia del mercado, con el posible apoyo de la Guardia di Finanza. Prevé además un canal de asesoramiento para microempresas y pymes, incluidas las start-ups, tarifas proporcionadas para la evaluación de la conformidad, un espacio de pruebas regulatorio (Sandbox-CRA) bajo la supervisión de la ACN y sanciones administrativas graduadas según la gravedad de la infracción.
A 12 de noviembre de 2026, la web del Gobierno italiano no recoge una aprobación definitiva y el decreto no se ha publicado en la Gazzetta Ufficiale: es un proyecto en tramitación, que puede cambiar. Las obligaciones de notificación, en cambio, derivan del reglamento europeo y ya se aplican. Si operas en España, consulta el estado de la normativa con las autoridades españolas competentes.
Lista de control: qué deben hacer hoy los fabricantes de software y dispositivos conectados
Estos son los pasos prácticos que conviene iniciar ya, por orden de prioridad. No sustituyen la lectura del reglamento y de las directrices, pero te ayudan a ver dónde tienes carencias.
1. Haz el inventario de productos
Enumera todos los productos de software y hardware que comercializas en la Unión, también los gratuitos, los que vendes desde hace años y los que tienen componentes en la nube. Para cada uno, anota versiones con soporte, países de venta, componentes de terceros y de código abierto y canales de actualización. Lo necesitas para saber qué productos ya están cubiertos por la obligación de notificación.
2. Clasifica rol y categoría
Para cada producto, aclara tu rol: fabricante, importador, distribuidor o administrador de software de código abierto. Comprueba si el producto entra en una categoría del anexo III o IV, si está excluido porque lo regulan otras normas y si un cambio que hagas puede ser sustancial. Las directrices de la Comisión ayudan en los casos dudosos.
3. Prepara el procedimiento de notificación
Redacta un procedimiento que indique quién decide, quién evalúa si una vulnerabilidad se explota activamente o si un incidente es grave, quién envía la alerta temprana, la notificación y el informe final y quién informa a los usuarios. Registra tu empresa en la plataforma única de ENISA, identifica el CSIRT competente y haz un simulacro de notificación con tu equipo. Las 24 horas cuentan desde que tienes conocimiento del hecho, también de noche o en fin de semana.
4. Organiza la gestión de vulnerabilidades y la divulgación coordinada
Publica un punto de contacto para las notificaciones de vulnerabilidades y una política de divulgación coordinada. Define cómo recibes, evalúas, corriges y comunicas las vulnerabilidades, también en componentes de terceros. Planifica pruebas de seguridad periódicas: para entender la diferencia entre las herramientas, lee la guía sobre pentesting y evaluación de vulnerabilidades y la del WAPT para aplicaciones web.
5. Prepara la lista de materiales de software
Empieza a generar una SBOM legible por máquina para cada versión publicada, con al menos las dependencias de primer nivel. Ya hoy te permite saber en pocas horas si una vulnerabilidad explotada en un componente afecta a tus productos, y desde 2027 es un requisito del reglamento.
6. Pon en marcha la documentación técnica
Prepara una plantilla de documentación técnica por producto basada en el anexo VII: evaluación de riesgos, arquitectura, procesos de gestión de vulnerabilidades, periodo de soporte e informes de ensayo. Mantenla actualizada en cada versión.
7. Planifica el camino hacia 2027
Fija un plan con responsables y plazos hasta el 11 de diciembre de 2027: diseño seguro, periodo de soporte, actualizaciones gratuitas, evaluación de la conformidad, declaración UE y marcado CE. Para una visión de conjunto de las fechas, lee la guía sobre los plazos de cumplimiento 2026-2027.
¿Qué relación tiene el Cyber Resilience Act con la ISO 27001 y la NIS2?
Son normas distintas, pero funcionan bien juntas. El Cyber Resilience Act se ocupa de la seguridad de los productos que introduces en el mercado; la Directiva NIS2, de la seguridad de las redes y sistemas de determinadas organizaciones; la ISO 27001 es una norma voluntaria para el sistema de gestión de la seguridad de la información.
Un sistema de gestión ISO 27001 ya te da una base sólida: evaluación de riesgos, gestión de incidentes, gestión de proveedores, control de cambios, documentación y mejora continua. No sustituye los requisitos de producto del reglamento, pero facilita aplicarlos con método. Para profundizar, lee la guía completa de la ISO 27001 y la de ISO 27001 y NIS2.
Si tu empresa también está sujeta a la NIS2, las obligaciones se suman: las notificaciones del Cyber Resilience Act se refieren a los productos y las de la NIS2 a los incidentes que afectan a tus servicios. Para las medidas básicas de partida, aunque no estés sujeto a la NIS2, lee la guía sobre medidas mínimas de ciberseguridad para pymes.
Cómo te ayuda Complaion con la seguridad de la información y el cumplimiento
Complaion acompaña a las empresas en la seguridad de la información y el cumplimiento normativo: certificación ISO 27001, adaptación a la NIS2, proyectos vinculados al Cyber Resilience Act y pruebas de seguridad con el servicio WAPT.
Un Lead Auditor dedicado sigue a tu empresa, analiza el punto de partida y te propone el camino más adecuado. La plataforma recoge las evidencias, gestiona documentos y procedimientos, controla los vencimientos y te prepara para la auditoría. El Lead Auditor realiza también la auditoría interna, para que sepas si tus procesos funcionan de verdad antes de las verificaciones externas.
Más de 1.000 clientes ya han elegido Complaion. Si quieres saber por dónde empezar, contáctanos.
Preguntas frecuentes sobre el Cyber Resilience Act
¿Desde cuándo tengo que notificar las vulnerabilidades explotadas activamente?
Desde el 11 de septiembre de 2026, si eres fabricante de productos con elementos digitales. La obligación también afecta a los productos ya comercializados antes del 11 de diciembre de 2027 (art. 69, apartado 3). La alerta temprana se envía en 24 horas desde que tienes conocimiento, a través de la plataforma única de notificación de ENISA.
¿Tengo que notificar todas las vulnerabilidades que encuentre?
No. La obligación se refiere a las vulnerabilidades explotadas activamente, es decir, aquellas con pruebas fiables de explotación maliciosa, y a los incidentes graves. Las demás vulnerabilidades deben gestionarse y corregirse igualmente según tu política, y pueden notificarse de forma voluntaria.
¿A quién se envía la notificación?
La notificación se envía a través de la plataforma única de ENISA, eligiendo el CSIRT designado como coordinador del Estado miembro en el que tienes tu establecimiento principal. Para Italia, la lista de ENISA remite al CSIRT Italia de la ACN; para otros países, consulta la misma lista. La notificación es accesible al mismo tiempo para ENISA.
¿El Cyber Resilience Act afecta también al software gratuito?
La definición de fabricante incluye también a quien comercializa productos a título gratuito o de monetización. En el caso del software libre y de código abierto, depende del contexto comercial: las directrices de la Comisión dedican una parte a este tema. Si tu caso no está claro, compruébalo con un consultor.
¿El periodo de soporte tiene que ser de cinco años?
El reglamento exige que refleje el tiempo de uso previsto del producto y fija al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo: en ese caso coincide con el tiempo de uso previsto. Esta obligación se aplica desde el 11 de diciembre de 2027.
¿El decreto italiano sobre el Cyber Resilience Act ya está en vigor?
No. El 2 de octubre de 2026 el Consejo de Ministros italiano lo aprobó en examen preliminar y, a 12 de noviembre de 2026, no se ha publicado en la Gazzetta Ufficiale. El proyecto designa a la ACN como autoridad de vigilancia del mercado y fija las sanciones nacionales. Las obligaciones de notificación del artículo 14, en cambio, derivan directamente del reglamento europeo y ya se aplican.
