Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

La notificación de 24h y 72h: cómo funciona la obligación aplicable desde el 11 de septiembre de 2026

Desde el 11 de septiembre de 2026, un fabricante que sepa de una vulnerabilidad aprovechada activamente en su producto tiene 24 horas para el primer aviso. Qué se notifica, a quién, por dónde, y qué conviene tener listo.

Publicado
Actualizado

Nota de actualización (23 oct 2026). Texto revisado después de que la obligación pasara a aplicarse: la plataforma de notificación funciona desde el 11 sep 2026, las orientaciones de la Comisión de 27 jul 2026 pasaron a ser la referencia citada, y se han añadido los componentes de terceros, el aviso a los usuarios y los productos ya introducidos en el mercado.

El artículo 14 del Cyber Resilience Act fue la primera gran obligación de los fabricantes en entrar en aplicación: el 11 de septiembre de 2026, quince meses antes de la aplicación plena. Desde esa fecha, un fabricante de productos con elementos digitales que tenga conocimiento de una vulnerabilidad aprovechada activamente, o de un incidente grave que afecte a la seguridad del producto, entra en un calendario medido en horas.

Qué dispara la obligación

Este punto es el peor comprendido. El artículo 14 no cubre todas las vulnerabilidades. Cubre dos cosas:

  • Vulnerabilidades aprovechadas activamente (el término del texto oficial; en la práctica se dice a menudo “explotadas activamente”): fallos en el producto para los que hay pruebas fiables de que un agente malintencionado los ha aprovechado en un sistema sin permiso de su propietario (art. 3, punto 42);
  • Incidentes graves que afecten a la seguridad del producto: los que afectan negativamente, o pueden afectar, a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, y los que provocan, o pueden provocar, la introducción o ejecución de código malicioso en el producto o en los sistemas del usuario (art. 14, apartado 5).

Una vulnerabilidad que el equipo descubre y corrige antes de que sea explotada sigue el proceso normal de gestión de vulnerabilidades. No abre ningún reloj de 24 horas.

El reloj empieza en el momento en que el fabricante tiene conocimiento. Las orientaciones de la Comisión de 27 de julio de 2026 (C(2026) 5252, no vinculantes) aclaran qué significa eso: hay conocimiento cuando, tras una evaluación inicial del evento sospechoso, el fabricante tiene un grado razonable de certeza de que hay explotación activa o incidente grave. El plazo cuenta a partir del resultado de ese triaje, lo que lo convierte en un proceso formal, con responsable y criterio escrito.

Con componentes de terceros (una biblioteca, un runtime, el servidor web de un panel de administración), la pregunta del triaje es si el fallo ha sido o está siendo aprovechado en el propio producto. Según las mismas orientaciones (punto 218), si el código vulnerable no es alcanzable en el producto, o si no ha habido explotación en él, no hay notificación obligatoria para ese fabricante. La explotación del componente en otros sistemas es una señal para ese triaje. La vulnerabilidad sigue entonces el proceso normal, que para los productos introducidos en el mercado a partir del 11 de diciembre de 2027 incluye comunicarla a quien mantiene el componente (art. 13, apartado 6). El artículo 09 aplica este criterio a los fallos de PHP y de Node.js corregidos el 21 de octubre de 2026.

La obligación cubre también el parque ya instalado. Por excepción expresa (art. 69, apartado 3), el artículo 14 se aplica a todos los productos incluidos en el ámbito, también a los introducidos en el mercado antes del 11 de diciembre de 2027, que por lo demás solo quedan sujetos al CRA si sufren una modificación sustancial. Las orientaciones de la Comisión añaden que la notificación sigue aplicándose después de terminado el período de soporte.

Los tres plazos

  1. 24 horas, notificación de alerta temprana. Deliberadamente escueta: existe una vulnerabilidad aprovechada activamente o un incidente grave, qué producto está afectado, y en qué Estados miembros sabe el fabricante que el producto se ha comercializado.
  2. 72 horas, notificación de vulnerabilidad (en los incidentes graves, notificación de incidente). Información general sobre el producto, la naturaleza del exploit y de la vulnerabilidad, medidas correctoras o paliativas ya adoptadas y las que los usuarios pueden adoptar.
  3. Informe final. Para vulnerabilidades: hasta 14 días después de que haya una medida correctora o paliativa disponible. Para incidentes graves: hasta un mes después de la notificación de incidente. Incluye descripción, gravedad e impacto, información sobre el actor malicioso cuando esté disponible, y detalles de la corrección.

Hay además un cuarto texto, este dirigido a los usuarios. Tras tener conocimiento, el fabricante debe informar a los usuarios afectados (y, cuando proceda, a todos los usuarios) de la vulnerabilidad o del incidente y, si es necesario, de las medidas paliativas o correctoras que pueden aplicar, cuando proceda en un formato estructurado y legible por máquina (art. 14, apartado 8). Si no lo hace a su debido tiempo, el CSIRT designado como coordinador puede hacerlo en su lugar.

Línea de tiempo del artículo 14: el conocimiento, determinado por el triaje, abre el reloj; notificación de alerta temprana a las 24 horas; notificación de vulnerabilidad o de incidente a las 72 horas; informe final 14 días después de que haya una medida correctora o paliativa, o un mes después de la notificación en los incidentes graves.
El calendario del artículo 14. El reloj se abre con el conocimiento, y eso es lo que hace del triaje un proceso formal.

A quién y por dónde

Se notifica una única vez, a través de la plataforma única de notificación prevista en el art. 16 (en inglés, Single Reporting Platform, SRP), que la ENISA puso en funcionamiento el 11 de septiembre de 2026. La notificación entra por el punto del CSIRT designado como coordinador del Estado miembro del establecimiento principal del fabricante (en Portugal, el CERT.PT, en el Centro Nacional de Cibersegurança) y queda simultáneamente accesible a la ENISA. Ese CSIRT difunde después la notificación a los CSIRT de los restantes Estados miembros donde el producto está disponible, y alimenta a las autoridades de vigilancia del mercado.

En circunstancias excepcionales, el CSIRT coordinador que recibe la notificación puede decidir aplazar su difusión a los demás CSIRT, durante el período estrictamente necesario y por motivos relacionados con la ciberseguridad, en particular a petición del fabricante (art. 16, apartado 2). El Reglamento Delegado (UE) 2026/881 fija las condiciones, por ejemplo una divulgación coordinada en curso en la que el CSIRT actúa como intermediario de confianza, o una medida paliativa que el fabricante prevé poner a disposición en un plazo de 72 horas. La decisión es del CSIRT, que debe informar de inmediato a la ENISA.

Un detalle con consecuencias: el “establecimiento principal” es el Estado miembro donde se toman predominantemente las decisiones sobre la ciberseguridad de los productos. Si no puede determinarse, cuenta aquel donde el fabricante tiene el establecimiento con mayor número de empleados en la Unión. Los fabricantes sin establecimiento principal en la Unión siguen una cascada, según la información de que dispongan: primero el Estado miembro del representante autorizado que actúa en nombre del fabricante para el mayor número de sus productos, después el del importador que introduce en el mercado el mayor número, después el del distribuidor que comercializa el mayor número y, por último, el Estado miembro con más usuarios. Conviene resolver esta cuestión antes de cualquier incidente: según las FAQ de la ENISA, una notificación enviada al CSIRT coordinador equivocado puede invalidarse y tener que reenviarse al correcto.

La plataforma, desde el 11 de septiembre de 2026

La ENISA abrió la SRP el 11 de septiembre de 2026, el mismo día en que el artículo 14 pasó a aplicarse, en una primera versión a la que llama “initial operating capability” (la entrada 004 del diario registró ese día). Tiene límites que conviene conocer antes de necesitarla: solo existe en inglés, no tiene API y todavía no recibe las notificaciones voluntarias del artículo 15.

Cada persona que vaya a notificar en nombre del fabricante necesita una cuenta EU Login con autenticación multifactor. El fabricante designa en la plataforma un representante principal y hasta 20 secundarios (assigned representatives, un papel de la plataforma que no debe confundirse con el representante autorizado del reglamento), y es el CSIRT coordinador quien valida esa asociación. La ENISA aconseja registrarse solo cuando haya algo que notificar; lo que se prepara antes es saber quién lo hará y ante qué CSIRT.

En la versión actual, el contador de 72 horas que muestra la plataforma parte del envío de la alerta temprana y marca 48 horas a partir de ahí. El plazo legal cuenta desde el momento en que se tuvo conocimiento, y esa es la hora que el registro interno tiene que guardar. Si la plataforma no está disponible, se puede contactar directamente con el CSIRT coordinador, pero el envío por la SRP sigue siendo obligatorio cuando vuelva. Una explotación de la que el fabricante ya tenía conocimiento antes del 11 de septiembre de 2026 no se notifica con carácter retroactivo; si solo tiene conocimiento después de esa fecha, notifica, aunque la vulnerabilidad sea anterior.

La conclusión práctica se mantiene: el proceso interno no depende de la herramienta y tiene que decir quién hace el triaje, quién decide “hemos tenido conocimiento”, quién redacta, quién aprueba, y con qué plantillas preescritas.

Qué significa esto para quien fabrica

La notificación de 24 horas no es un problema de comunicación; es un problema de preparación. Cuatro piezas que cualquier fabricante, de cualquier tamaño, puede montar, y que desde el 11 de septiembre de 2026 ya deberían estar listas:

  1. Señales que alimentan el triaje. Monitorización de las fuentes que levantan la sospecha de que una “vulnerabilidad conocida” ha pasado a “aprovechada activamente”: los avisos del CERT-EU y del CSIRT nacional (en Portugal, el CERT.PT), los avisos de quienes mantienen los componentes de la SBOM, incluidos los preanuncios de versiones de seguridad, el catálogo KEV de la CISA, y el canal de recepción de informes externos (la política de divulgación coordinada de vulnerabilidades que el propio CRA exige). El KEV es un catálogo estadounidense, con criterios propios, y puede llegar después de los primeros indicios de explotación: que una CVE no figure en el KEV no prueba que no haya explotación. La pregunta que responde el triaje es si el fallo ha sido o está siendo aprovechado en el producto.
  2. Una decisión de conocimiento con responsable. Quién puede declarar, y con qué criterio, que la empresa “ha tenido conocimiento”. Sin ese criterio escrito, nadie sabe con certeza cuándo empezó a correr el plazo.
  3. Los textos preescritos. La alerta temprana de 24h cabe en media página; escribirla durante el incidente es el peor momento. Plantillas rellenables para las tres notificaciones y para el aviso a los usuarios, aprobadas de antemano.
  4. El ensayo. Un ejercicio de mesa por semestre, con escenario realista, midiendo una cosa: cuánto tiempo pasa entre la señal y la alerta temprana lista para enviar.

En una microempresa, todo esto cabe en media docena de páginas y en una tarde de ejercicio. Lo que no cabe es improvisarlo a las 3 de la madrugada de un jueves.

Fuentes