Tres plataformas de load balancer, tres RCE críticos y una pregunta que sigue llegando a los buzones de seguridad y cumplimiento: ¿una vulnerabilidad no parcheada en la capa de appliance activa el reloj de notificación DORA o permanece en el registro de riesgo operativo hasta que algo falle de verdad? La respuesta no es binaria, y equivocarse en cualquier dirección tiene consecuencias reales.
En agosto de 2025 se publicó CVE-2025-7775, un desbordamiento de memoria en Citrix NetScaler ADC y NetScaler Gateway que permite ejecución remota de código sin autenticación, explotado activamente como zero-day en configuraciones VPN, ICA Proxy, AAA y servidores virtuales de load balancing. En septiembre llegó CVE-2025-20333, un RCE con CVSS 9.9 en Cisco ASA y FTD atribuido a un actor estatal sofisticado. Más recientemente, F5 divulgó CVE-2026-94127, un fallo CVSS 9.8 en sistemas BIG-IP APM configurados como servidores de autorización OAuth, publicando hotfixes de ingeniería mientras los detalles de explotación aún estaban emergiendo. Solo Citrix registró casi un 23 % más de vulnerabilidades publicadas en el segundo trimestre de 2025 que en el primero. El ritmo no se está ralentizando.
Para una entidad financiera sujeta a DORA, el Reglamento (UE) 2022/2554 que se aplica directamente desde el 17 de enero de 2025, cada una de estas divulgaciones exige una decisión de clasificación antes de exigir un ticket de parcheo.
La pregunta de clasificación que DORA realmente plantea
DORA traza una línea legal precisa entre una ciberamenaza, un incidente relacionado con las TIC y un incidente mayor relacionado con las TIC. Esa línea determina si tu obligación es el análisis interno, la notificación voluntaria o la notificación regulatoria obligatoria con plazos estrictos.
Un CVE de RCE divulgado públicamente que afecta a tu load balancer, sin explotación confirmada en tu propio appliance, se encuadra en la categoría de amenaza. El Reglamento Delegado (UE) 2024/1772 define los criterios para el estatus de «ciberamenaza significativa»: actores de amenaza con capacidad e intención demostradas, TTPs dirigidos a funciones críticas o importantes, e indicadores que sugieren inminencia, como reconocimiento activo, credenciales expuestas o compromiso de la cadena de suministro aguas arriba. En virtud del artículo 19(2) de DORA, la notificación voluntaria a tu autoridad competente está disponible para ciberamenazas significativas, pero no es obligatoria.
En el momento en que existe acceso malicioso, no autorizado y confirmado a tus redes y sistemas de información, la amenaza se convierte en incidente. Si se ven afectadas funciones críticas o importantes, casi con certeza es un incidente mayor.
La prueba operativa está en el artículo 8(1) del RTS 2024/1772: un incidente es mayor cuando afecta a servicios o sistemas TIC que respaldan funciones críticas o importantes Y se ha producido un acceso no autorizado, malicioso y exitoso a redes y sistemas de información, o bien se cumplen al menos otros dos umbrales de materialidad. Esos umbrales incluyen más del 10 % o 100 000 clientes afectados, una interrupción superior a 2 horas en servicios críticos, impacto en dos o más Estados miembros, o costes que probablemente superen los 100 000 €. Un load balancer no se menciona explícitamente en el texto de DORA, pero cualquier appliance que soporte redes y sistemas de información para funciones críticas o importantes queda plenamente dentro de la definición de activos TIC cubiertos del artículo 3(18). Esa inferencia es jurídicamente sólida aunque todavía no se haya plasmado en orientaciones supervisoras publicadas.
La mecánica de los plazos importa tanto como la clasificación
Una vez que un incidente se clasifica como mayor, el Reglamento Delegado de la Comisión (UE) 2025/301 activa tres relojes simultáneamente. La notificación inicial a tu autoridad competente debe realizarse en un plazo de 4 horas desde la clasificación y dentro de las 24 horas siguientes a la detección. Un informe intermedio sigue en un plazo de 72 horas tras la notificación inicial. El informe final vence un mes después del último informe intermedio. El reloj de 4 horas corre desde el momento de la clasificación, no desde la detección. Una entidad que detecta una brecha a las 09:00 pero no la clasifica hasta las 14:00 tiene hasta las 18:00 para la notificación inicial, pero ya ha consumido cinco horas de investigación sin que el reloj corriera. Retrasar la clasificación no es un margen de maniobra; es un fallo de gobernanza que se agrava bajo el artículo 19.
El contenido, el formato y las plantillas de esos informes se especifican en el Reglamento de Ejecución de la Comisión (UE) 2025/302. No notificar a tiempo constituye una infracción sancionable. La implicación práctica es que tu runbook de respuesta a incidentes para CVEs en la capa de appliance necesita una puerta de clasificación con una marca de tiempo documentada, no solo un ticket de remediación.
Lo que debe decir tu contrato de servicios gestionados
Aquí es donde el argumento de la infraestructura soberana deja de ser retórico y se vuelve concreto. El artículo 28 de DORA establece que las entidades financieras son plenamente responsables de sus obligaciones DORA independientemente de cuánta prestación TIC esté contratada con terceros. El artículo 30(3) exige cláusulas específicas para cualquier acuerdo que respalde una función crítica o importante, incluyendo plazos de notificación de incidentes del proveedor alineados con la ventana de notificación de 4 horas de la entidad, derechos de auditoría e inspección sin restricciones, y estrategias de salida con períodos de transición adecuados.
De los 19 proveedores críticos de TIC terceros designados por las Autoridades Europeas de Supervisión en noviembre de 2025, la mayoría tienen sede en Estados Unidos: AWS, Microsoft Azure, Google Cloud, IBM, Oracle y otros. Un load balancer gestionado por cualquiera de esos proveedores queda bajo la supervisión directa del Equipo Conjunto de Examen de las ESA, lo que añade una capa regulatoria que afecta a tus propias obligaciones de auditoría. Los contratos firmados antes del 17 de enero de 2025 deben renegociarse para incluir cláusulas conformes con DORA; el texto del reglamento no contempla ningún período de gracia.
DORA no prescribe un SLA numérico de parcheo. Los artículos 9 y 10 exigen un proceso documentado y basado en el riesgo para la gestión de vulnerabilidades y parches, pero el reglamento deja los plazos concretos a la negociación en las disposiciones SLA del artículo 30. Eso significa que la cifra de «CVEs críticos en 48 horas» que puedes haber visto en materiales de proveedores es un término contractual, no un mínimo regulatorio, y debe constar por escrito, con mecanismos de enforcement, antes de que ocurra un incidente.
Cómo construir el marco de decisión
El marco práctico para un CVE en un appliance de red tiene cuatro puertas. Primera: ¿el appliance afectado respalda una función crítica o importante? Si la respuesta es sí, el CVE entra de inmediato en una evaluación de riesgo formal, no en una cola de parcheo rutinaria. Segunda: ¿existe acceso malicioso, no autorizado y confirmado en tu entorno? Si la respuesta es sí, clasifica como posible incidente mayor, registra la marca de tiempo de clasificación y abre la ventana de notificación de 4 horas. Tercera: ¿el incidente cumple al menos dos umbrales de materialidad del artículo 8(1) del RTS 2024/1772, o implica acceso no autorizado confirmado por sí solo? Si la respuesta es sí, se aplica la notificación obligatoria de incidente mayor. Cuarta: si la explotación no está confirmada pero el perfil del actor de amenaza y los TTPs cumplen los criterios de ciberamenaza significativa, considera la notificación voluntaria en virtud del artículo 19(2) y documenta la decisión en cualquier caso.
Nuestro equipo de SecOps aplica exactamente esta lógica de puertas cuando aparece un nuevo CVE en un appliance. Las reglas de correlación en el SIEM que detectan movimiento lateral o intentos de autenticación anómalos en las interfaces de gestión del load balancer constituyen la capa de detección; el árbol de decisión de clasificación es la capa de gobernanza. Ambas deben existir antes de que el CVE llegue a los medios, porque el reloj de 4 horas no espera a que diseñes el proceso.
El SLA de parcheo es un problema contractual, no solo técnico
CVE-2025-7775 afectó a las versiones 13.1, 14.1, 13.1-FIPS y NDcPP de NetScaler en múltiples configuraciones. Citrix publicó correcciones, pero la ventana entre la divulgación pública y el despliegue del parche en un entorno distribuido es donde se concentra la exposición. Para un proveedor de servicios gestionados que opera tu capa de load balancer, la pregunta contractual no es si van a parchear, sino con qué rapidez, con qué evidencia de finalización, y quién asume la obligación de notificación DORA si se confirma la explotación antes de que el parche esté desplegado.
El control de infraestructura soberana simplifica considerablemente esa negociación. Cuando el proveedor opera bajo legislación europea, responde ante autoridades supervisoras europeas y no tiene una empresa matriz extranjera que pueda recibir órdenes legales contradictorias, el alineamiento contractual en materia de notificación de incidentes y derechos de auditoría es estructuralmente más sencillo. La dirección del proveedor es una variable de gobernanza, no solo un argumento de marketing.
