La UE activa el 11 de septiembre los avisos de fallos explotados

<strong>Una luz ámbar en un router no obliga a esperar hasta 2027 para iniciar el aviso.</strong> A partir del 11 de septiembre de 2026, determinados fallos explotados e incidentes graves en productos digitales activarán un reloj europeo de 24 horas. La primera comunicación puede ser breve; el análisis se completa después. La novedad es el orden: avisar primero, investigar y corregir sin convertir la espera del informe definitivo en silencio.

La fecha afecta sobre todo a quienes fabrican y comercializan hardware o software en la Unión Europea, pero su significado llega hasta el usuario. El <a href="https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=OJ:L_202402847" target="_blank" rel="noopener noreferrer">Reglamento (UE) 2024/2847</a>, conocido como Reglamento de Ciberresiliencia o CRA por sus siglas en inglés, separa la notificación a las autoridades de la obligación de informar a las personas afectadas y de ofrecer medidas correctoras o de reducción del riesgo.

También separa dos calendarios que pueden confundirse. Septiembre no convierte de golpe todos los productos conectados que están en una tienda en plenamente conformes con la nueva norma. Abre la fase obligatoria de los avisos. El grueso de los requisitos de diseño seguro, gestión de vulnerabilidades, soporte, documentación y evaluación de la conformidad se aplicará desde el 11 de diciembre de 2027.

Dos fechas, dos cambios distintos

El artículo 71 fija la regla general: el Reglamento será aplicable desde el <strong>11 de diciembre de 2027</strong>. A continuación establece la excepción: el artículo 14, dedicado a las obligaciones de información de los fabricantes, se aplica desde el <strong>11 de septiembre de 2026</strong>. La fase institucional comenzó antes, en junio, para que se designaran autoridades notificantes y de vigilancia del mercado.

Esta escalera evita que el sistema de alerta tenga que construirse el mismo día en que entra el resto de la norma. La plataforma, los equipos nacionales de respuesta a incidentes (los CSIRT) y ENISA necesitan recibir y distribuir información sensible antes de que el régimen completo de productos sea exigible. Para una empresa, por tanto, “prepararse para 2027” no basta si todavía no puede reconocer y comunicar un caso sujeto al artículo 14.

Para el comprador, la distinción corrige una expectativa excesiva. El 11 de septiembre no aparecerá una nueva etiqueta universal en cada caja ni se producirá una retirada automática de todos los equipos antiguos. El cambio ocurre primero en el circuito de detección, aviso, coordinación y corrección. La información visible sobre soporte y conformidad pertenece en gran medida a la etapa de 2027.

No se notifica cada error de software ni cada caída del servicio

El primer disparador es una <strong>vulnerabilidad aprovechada activamente</strong>. El Reglamento la define como una vulnerabilidad para la que existe una prueba fiable de que un agente malintencionado la ha utilizado en un sistema sin permiso de su propietario. Que un investigador encuentre un fallo, que exista una prueba de concepto pública o que un escáner lo marque no demuestra por sí solo esa explotación activa.

El segundo disparador es un <strong>incidente grave</strong> que repercute en la seguridad del producto. El artículo 14 considera grave el incidente que afecta o puede afectar negativamente a la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes. También incluye el caso que ha llevado o puede llevar a introducir o ejecutar código malicioso en el producto o en la red del usuario.

Ese umbral deja fuera la traducción automática de cualquier avería en “ciberincidente grave”. Una interrupción eléctrica, un error puramente estético o un fallo sin impacto de seguridad requieren atención, pero no necesariamente una notificación CRA. La empresa debe documentar por qué un hecho entra o no entra: el reloj empieza cuando el fabricante tiene conocimiento, no cuando el comité termina de debatir el nombre del problema.

La secuencia es 24 horas, 72 horas y un informe final

La <a href="https://digital-strategy.ec.europa.eu/en/policies/cra-reporting" target="_blank" rel="noopener noreferrer">Comisión Europea resume la primera etapa</a> como una alerta temprana sin demora indebida y, en todo caso, dentro de las <strong>24 horas</strong> siguientes al conocimiento. Para una vulnerabilidad explotada, debe indicar cuando proceda los Estados miembros donde el producto se ha comercializado. Para un incidente grave, debe señalar al menos si se sospechan actos ilegales o malintencionados.

En un máximo de <strong>72 horas</strong> llega la notificación ampliada. En la vulnerabilidad recoge la información general disponible sobre el producto, la naturaleza del fallo y de su explotación, las medidas adoptadas y lo que el usuario puede hacer. En el incidente incorpora una evaluación inicial, su naturaleza y las medidas correctoras o paliativas. No se exige conocer en tres días toda la causa raíz; sí aportar lo disponible y distinguir los hechos de una valoración preliminar.

El cierre tiene dos plazos. Para una vulnerabilidad explotada, el informe final vence como máximo 14 días después de que exista una medida correctora o paliativa, como una actualización. Para un incidente grave, vence dentro de un mes después de la notificación de 72 horas. El CSIRT puede solicitar entretanto un informe provisional con cambios relevantes de la situación.

Una sola entrada no significa una sola autoridad

Las comunicaciones se presentan en la <strong>plataforma única de notificación</strong> de ENISA. Su función es que el fabricante comunique una vez, en lugar de repetir el mismo expediente ante múltiples organismos nacionales. La <a href="https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions" target="_blank" rel="noopener noreferrer">información operativa de ENISA, actualizada el 3 de agosto</a>, confirma que la plataforma estará disponible cuando empiece la obligación y que las pruebas funcionales y de seguridad están en marcha.

El fabricante selecciona el CSIRT coordinador determinado, en general, por el lugar de su establecimiento principal en la UE. La notificación queda accesible simultáneamente para ENISA y el CSIRT la distribuye a los equipos de los Estados miembros donde el producto está disponible, además de facilitar a las autoridades de vigilancia del mercado lo que necesitan para ejercer sus funciones. Si el fabricante está fuera de la Unión, el Reglamento establece una prelación basada en su representante autorizado, importador, distribuidor o usuarios.

No es un tablón público de vulnerabilidades sin corregir. La plataforma debe proteger la confidencialidad y, en circunstancias excepcionales justificadas por seguridad, la difusión puede aplazarse. ENISA incorporará una vulnerabilidad conocida públicamente a la base europea de vulnerabilidades una vez que exista una actualización u otra medida y de acuerdo con el fabricante. Un CSIRT puede informar al público si resulta necesario para prevenir o mitigar un incidente grave.

Los productos que ya estaban en el mercado también entran en el aviso

La regla transitoria es especialmente importante para routers, cámaras, aplicaciones o componentes con varios años de vida. El artículo 69 dispone que los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos al resto de los requisitos si sufren después una modificación sustancial. Pero hace una excepción expresa para el artículo 14: las obligaciones de notificación se aplican a todos los productos dentro del ámbito, aunque se hubieran comercializado antes.

Eso no obliga a presentar el 11 de septiembre un inventario retroactivo de cada vulnerabilidad conocida durante años. ENISA aclara que la obligación nace cuando el fabricante tiene conocimiento y que no se extiende a explotaciones de las que ya era consciente antes de que la obligación empezara a aplicarse. Un hecho nuevo, o el conocimiento posterior de explotación activa, sí puede poner en marcha el reloj aunque el modelo sea antiguo.

El ámbito cubre ampliamente equipos y programas informáticos con una conexión lógica o física directa o indirecta, junto con determinadas soluciones de tratamiento de datos a distancia necesarias para que el producto cumpla sus funciones. Monitores de bebés, relojes inteligentes, aplicaciones, routers y programas informáticos sirven como ejemplos, pero existen exclusiones y regímenes sectoriales. Compartir código abierto fuera de una actividad comercial tampoco equivale automáticamente a ser fabricante; los responsables de software de código abierto tienen un tratamiento específico.

El usuario afectado debe recibir algo más que un silencio administrativo

La notificación a la plataforma no sustituye el contacto con quien usa el producto. Cuando conoce una vulnerabilidad aprovechada activamente o un incidente grave, el fabricante debe informar a los usuarios afectados y, cuando proceda, a todos sobre el problema, los riesgos y las medidas que pueden adoptar. Si no lo hace a tiempo, el CSIRT coordinador puede facilitar la información cuando sea proporcionado y necesario para prevenir o reducir el impacto.

Para una persona en España, la consecuencia práctica no es vigilar la plataforma de ENISA cada mañana. Es mantener habilitadas las actualizaciones de seguridad cuando resulte razonable, conservar el nombre y modelo exactos, revisar el canal oficial del fabricante y desconfiar de correos que usen una noticia sobre una vulnerabilidad para pedir credenciales. Un aviso legítimo debe permitir comprobar la actualización o la medida en un dominio oficial sin obligar a entregar una contraseña por un enlace recibido.

Los lectores de América Latina pueden beneficiarse si usan el mismo producto y el fabricante distribuye una corrección global, pero no deben asumir que el procedimiento europeo crea por sí solo un derecho idéntico ante su autoridad nacional. El criterio regulatorio es la comercialización en la UE; el alcance de una actualización, una retirada o un aviso fuera de ese mercado puede depender del fabricante y de la legislación local.

Qué debe estar preparado antes de que empiece el reloj

• <strong>Un inventario con propietario.</strong> Vincule cada producto y versión, incluidos los modelos antiguos, a un equipo capaz de decidir si el artículo 14 se aplica.
• <strong>Una definición interna de conocimiento.</strong> Los avisos de clientes, proveedores, investigadores, telemetría y equipos de respuesta necesitan una entrada común y una persona de guardia; el plazo no espera a que llegue el lunes.
• <strong>Una alerta mínima viable.</strong> Prepare los campos de 24 horas por separado del análisis de 72 horas. La falta de una causa raíz completa no debe bloquear la primera comunicación.
• <strong>Un mapa de componentes y mercados.</strong> Una biblioteca de terceros puede aparecer en muchos productos, y la notificación pide saber dónde se han comercializado.
• <strong>Un mensaje verificable para usuarios.</strong> Redacte de antemano cómo publicará una actualización, una mitigación o una retirada sin exponer detalles que empeoren el riesgo.
• <strong>Un ensayo manual.</strong> ENISA indica que en esta etapa no habrá una API para automatizar envíos masivos; los procesos internos pueden automatizarse, pero el acceso y los campos de la plataforma deben probarse como realmente estarán disponibles.

La primera obligación visible del Reglamento de Ciberresiliencia no será una pegatina ni una promesa de que ningún dispositivo volverá a fallar. Será una cadena de tiempo: detectar, clasificar, avisar, ampliar, corregir e informar. El 11 de septiembre arranca esa cadena. La transformación completa del producto llega quince meses después.