Cyber Resilience Act: las obligaciones de notificación del 11 de septiembre de 2026, explicadas

El reglamento europeo de ciberresiliencia abre mañana su primer capítulo vinculante: la notificación de vulnerabilidades explotadas. Qué exige el texto, a quién y por qué cambia la cuestión cuando tu programa es una herramienta interna.

Las obligaciones de notificación del Cyber Resilience Act se aplican desde el 11 de septiembre de 2026, indica la página oficial de la Comisión Europea dedicada al reglamento. Esa misma página recuerda que el texto entró en vigor el 10 de diciembre de 2024 y que sus obligaciones principales se aplicarán el 11 de diciembre de 2027.

Lo que cubre el reglamento

La Comisión describe un ámbito amplio: desde monitores de bebés hasta relojes conectados, desde aplicaciones hasta programas informáticos, hardware y software que puedan conectarse. El reglamento impone a los fabricantes requisitos de ciberseguridad sobre la planificación, el diseño, el desarrollo y el mantenimiento de estos productos y prevé un marcado CE que acredite la conformidad. Se reserva un tratamiento particular al software libre y abierto por su lugar en la cadena, sin que la página detalle las exenciones. Determinar si tu producto entra en este ámbito debe hacerse con tu asesor jurídico, y la respuesta suele depender de un detalle contractual más que de la naturaleza del programa.

Quién asume la obligación

El texto se dirige a quien comercializa un producto, no a quien lo utiliza. La obligación corresponde al proveedor del programa, no al despacho que lo compra y usa. La distinción se vuelve interesante cuando un directivo encarga una herramienta y se pregunta de qué lado está. Una herramienta interna, que nunca se vende ni distribuye, no responde a la misma lógica que un producto ofrecido a clientes. Entre ambos existe una zona gris que solo resuelve un dictamen jurídico: una aplicación puesta a disposición de tus franquiciados, un módulo revendido con un servicio o un acceso abierto a tus clientes como parte de una suscripción. Muchos directivos descubren que son proveedores de software el día que lo facturan.

Lo que la Comisión no dice en su página

La prensa especializada cita plazos de notificación de 24 horas, 72 horas y 14 días. La página de la Comisión no los menciona y no pudimos leer el texto del reglamento en la fuente directa. Por tanto, los dejamos de lado en lugar de repetirlos, aunque demos menos detalles que otros artículos publicados esta semana. Lo establecido cabe en una frase: desde el 11 de septiembre de 2026, un fabricante afectado debe notificar las vulnerabilidades explotadas de su producto, incluso si fue entregado antes de esa fecha. Lo demás, incluida la cuenta atrás exacta, se comprueba en el reglamento con tu asesor.

La verdadera cuestión para un directivo

La obligación de notificar presupone dos capacidades que pocas pequeñas organizaciones tienen: saber que se está explotando una vulnerabilidad y saber quién la corrige. Una aplicación construida en unas noches con un generador, publicada y después olvidada no cumple ninguna. Nadie vigila, nadie mantiene la lista de componentes incluidos y la cuestión de la propiedad del código surge en el peor momento. Lo detallamos en lo que queda en tus manos cuando cierra una herramienta: sin el código y sin el documento que lo describe, una corrección urgente se convierte en un trabajo de varias semanas, y la persona capaz de hacerlo no siempre está localizable en agosto.

Existe una versión más elemental del problema que se comprueba en dos minutos: una base de datos abierta no espera a 2027 para costarte cara. Las reglas de acceso son, además, el muro contra el que chocan la mayoría de las herramientas de generación rápida, como muestra la comparación de esta mañana en dos plataformas muy distintas. Un producto que nunca tuvo documento de requisitos tampoco tuvo nunca una lista escrita de quién accede a qué.

En la práctica, esta semana

Bastan tres líneas para saber dónde estás. Una: escribe si tu programa sale de tu empresa, vendido, distribuido o puesto a disposición, o si sigue siendo una herramienta interna. Dos: nombra a la persona que te avisa cuando se comunica una vulnerabilidad en un componente de tu producto, con su nombre, no su departamento. Tres: di dónde vive el código y por qué vía aplicarías una corrección sin esperar el permiso de una plataforma. Lleva las respuestas a tu asesor junto con la pregunta sobre el ámbito de aplicación. En Maestro, el código y los documentos permanecen en tu Mac, lo que responde a la tercera línea y solo a ella: la conformidad de un producto sigue siendo el trabajo de quien lo comercializa y ninguna herramienta la asume por ti.