Ir al contenido
11 días para la obligación de notificación del art. 14 (11 de septiembre de 2026).
Documentación Soporte Clase de riesgo
03Blog y análisis · Reglamento · 5 de agosto de 2026 · 8 min de lectura

Notificada vs explotada: la diferencia de 15 millones

La alerta temprana de 24 horas no se debe por cada vulnerabilidad que aterriza en su buzón. Se debe solo cuando hay evidencia fiable de que alguien la explotó, sin autorización, en un sistema real. Todo depende de una línea escrita: la calificación del suceso.

Código fuente en revisión en una pantalla
Foto: Pankaj Patel / Unsplash

Dónde empieza realmente la obligación

El Cyber Resilience Act no le pide notificar vulnerabilidades. Le pide notificar vulnerabilidades explotadas activamente. La distinción no es retórica: está escrita en la propia definición del art. 3(42), y todo el reloj de 24 horas del art. 14 cuelga de ella.

El disparador no es la existencia de un fallo, ni que alguien se lo haya contado. El disparador es la evidencia fiable de que un actor malicioso la ha usado, en un sistema, sin la autorización del propietario. La divulgación responsable de un investigador, un artículo académico, un escaneo automático que marca una biblioteca desactualizada: nada de eso, por sí solo, arranca el reloj.

Art. 3(42)Vulnerabilidad explotada activamente: vulnerabilidad de la que existen elementos fiables de que un actor malicioso la ha explotado en un sistema sin la autorización del propietario.

El riesgo corre en ambos sentidos

Notifique de menos y viola la obligación. Notifíquelo todo, sin distinción, y paga otro precio: pierde credibilidad ante el CSIRT, ahoga a su propio equipo en presentaciones y quema las horas que necesitaría para la única notificación que importa. Sobrenotificar no es una opción segura por defecto. Es una forma más lenta de fallar.

La salida de ambos riesgos es la misma, y no tiene glamur: una calificación motivada, tomada deprisa y puesta por escrito. Un «no» documentado es una defensa que puede entregar a un inspector. Un «no» implícito — la notificación que decidió en silencio no presentar — es indistinguible de la negligencia cuando alguien pregunta, meses después, por qué no se envió nada.

Tres casos, y la línea que escribiría para cada uno

La calificación se enseña mejor con ejemplos que con definiciones. Aquí hay tres recurrentes, con el razonamiento exacto que anotaríamos en el registro — no un veredicto, sino la evidencia y la conclusión extraída de ella.

Caso 1 — Correo de un investigador con PoC

Un investigador de seguridad escribe a su dirección de divulgación. Adjunta una prueba de concepto que dispara de forma fiable un desbordamiento de búfer en el firmware actual. No hay afirmación, ni evidencia, de que alguien lo haya usado contra un dispositivo real de un cliente.

Notificada, no explotada. Línea de registro: «Vulnerabilidad confirmada, PoC funcional recibido de investigador externo el [fecha]. Sin evidencia de explotación en ningún sistema sin autorización. Art. 3(42) no cumplido → sin alerta temprana del art. 14. Gestionada bajo el proceso de divulgación coordinada; abierto el calendario de remediación.»

Caso 2 — Evidencia de honeypot y registros

Su honeypot captura una carga que explota el mismo desbordamiento, y los registros de producción de dos instalaciones de clientes muestran el patrón de peticiones idéntico seguido de una conexión saliente a un host desconocido. El comportamiento coincide con un uso activo en el mundo real, contra sistemas que nadie autorizó.

Explotada. Presente la alerta temprana. Línea de registro: «Evidencia fiable de explotación sin autorización: carga de honeypot + registros de producción coincidentes en dos sitios, [marcas temporales]. Art. 3(42) cumplido → alerta temprana del art. 14 presentada al CSIRT en las 24 h desde [hora del conocimiento]. Actualización de 72 h e informe final programados.»

Caso 3 — El escáner marca una dependencia desactualizada

Un escáner nocturno de dependencias marca una CVE en una versión antigua de una biblioteca incluida en su producto. No hay notificación de una vulnerabilidad en su producto, ni PoC contra su build, ni señal de explotación en ninguna parte. Solo un número de versión por debajo de un umbral.

Ninguna de las dos — pero documéntelo. Línea de registro: «Marca del escáner en la biblioteca [nombre/versión], CVE [id]. Aún no confirmada como vulnerabilidad explotable en nuestro producto; sin evidencia de explotación. Art. 3(42) no cumplido → sin obligación del art. 14 hoy. Abierto el triaje para confirmar la alcanzabilidad; si afecta a un componente de terceros, valorar la notificación aguas arriba del art. 13(6).»

Por qué «15 millones» está en el título

Las obligaciones de notificación de los arts. 13 y 14 están en la banda sancionadora más alta del reglamento: hasta 15 millones de euros, o el 2,5 % del volumen de negocios anual mundial total del ejercicio anterior, lo que sea mayor. La cifra no es una táctica de miedo. Es el techo que el legislador ató específicamente a los deberes de gestión y notificación de vulnerabilidades.

Lo que una autoridad pondera, en la práctica, no es si acertó por casualidad. Es si tenía un proceso y lo aplicó. Dos empresas pueden llegar al mismo «no» — una por silencio, otra con una entrada de registro fechada que cita el art. 3(42). Solo la segunda puede demostrarlo. La calificación no es papeleo alrededor de la decisión; la calificación es la decisión.

El test en una línea ¿Hay evidencia fiable de que un actor malicioso la explotó, en un sistema, sin autorización? Si sí → alerta temprana en 24 h. Si no → un «no» escrito y motivado.

Este artículo describe nuestra lectura del texto normativo y no constituye asesoramiento jurídico.

Clase de riesgo