Al regulador que inventó el catálogo KEV le han bastado menos de cinco años para retirar el plazo único que lo acompañaba. El 10 de junio de 2026, CISA revocó las dos directivas que ordenaban el parcheo de la administración federal estadounidense desde 2019 y las sustituyó por la BOD 26-04, «Prioritizing Security Updates Based on Risk». Cuatro preguntas por cada fallo deciden ahora si se corrige en tres días (con o sin triaje forense), en catorce, en sesenta o en la siguiente actualización programada.
La directiva solo obliga a las agencias federales civiles de EE. UU. Aun así, vale la pena estudiarla desde Europa: es probable que llegue antes por la vía del auditor y del cliente que por la del regulador.
Qué cambia exactamente con la BOD 26-04
La nueva directiva revoca la BOD 19-02 (2019), que fijaba plazos de remediación para sistemas accesibles desde internet, y la BOD 22-01 (2021), la que creó el catálogo KEV de vulnerabilidades con explotación confirmada. Aquella regla era simple: si un CVE entraba en el KEV, había que corregirlo en 14 días (seis meses para los anteriores a 2021), sin importar dónde estuviera el activo ni qué permitiera el fallo.
El nuevo esquema sustituye ese plazo único por una matriz. Cada vulnerabilidad se evalúa con cuatro preguntas binarias y la combinación de respuestas determina la urgencia: 16 combinaciones posibles, repartidas en cinco niveles de respuesta.
Las cuatro preguntas
- ¿Está el activo expuesto públicamente, con una dirección IP alcanzable desde fuera de la red? Es la única variable que cada organización debe responder con su inventario.
- ¿Figura el CVE en el catálogo KEV? Su presencia allí confirma la explotación en el mundo real.
- ¿Puede el atacante automatizar todos los pasos necesarios para explotar el fallo?
- ¿Concede el fallo control total del activo en caso de explotarse con éxito?
Las respuestas a las tres últimas las publica CISA: la explotación la confirma el catálogo KEV, y la automatización y el impacto salen de Vulnrichment, su programa apoyado en SSVC (la metodología de categorización que mantiene la agencia), para los CVE que cubre. La carga real para cada organismo está en la primera pregunta: saber en todo momento qué activos están expuestos exige un inventario vivo de la superficie de ataque, no un escaneo trimestral.
Los cinco niveles de respuesta
El nivel más exigente, tres días con triaje forense obligatorio, se aplica cuando el fallo está en el KEV y concede control total del sistema. Le siguen un segundo nivel de tres días sin triaje, para ciertas combinaciones de alto riesgo aunque el CVE aún no esté en el KEV, y los 14 días como plazo acelerado estándar. En el otro extremo quedan los 60 días para las combinaciones de menor riesgo y la siguiente actualización programada cuando no se cumple ningún criterio.
Los plazos, además, no son estáticos: si CISA añade el CVE al KEV, la ventana se acorta de inmediato; si el organismo responsable retira el activo de internet, se alarga. Un dato del piloto de CISA pone esas ventanas en perspectiva. En la prueba sobre una gran organización civil, recogida por Tenable en su revisión de la directiva, solo el 1 % de las detecciones de vulnerabilidad caía en los niveles de tres días. Más del 60 % podía aplazarse a la siguiente actualización. El modelo concentra el esfuerzo en una fracción pequeña del parque.
El triaje forense del nivel máximo es la novedad menos comentada y la más exigente de aplicar. La directiva asume algo que muchos programas de parcheo prefieren no mirar: si un fallo con explotación activa llevaba días abierto en un activo expuesto, parchear no basta. Hay que comprobar si alguien entró antes de cerrar la puerta, y esa comprobación es trabajo de análisis forense.
«Es una directiva de Washington; mi empresa no está obligada»
Es cierto, y hay que decirlo sin rodeos: la obligación alcanza únicamente a las agencias federales civiles estadounidenses. Estas deben actualizar sus políticas de inmediato, revisar sus procesos en 60 días y cumplir los plazos completos de la matriz en 180, hacia diciembre de 2026.
La segunda objeción es operativa: tres días para parchear una plataforma crítica suena inviable para un equipo que ya va justo. Quien administra un vCenter o un ERP en producción sabe que un parche urgente compite con ventanas de cambio, pruebas de regresión y dependencias que no desaparecen porque lo diga una directiva extranjera.
Por qué va a acabar en tu comité de todos modos
El precedente pesa: la BOD 22-01 tampoco alcanzaba a nadie fuera del gobierno federal de EE. UU. y su catálogo KEV terminó siendo una de las referencias de priorización más citadas del sector. Lo usan aseguradoras, auditores y marcos de control, y es una de las tres referencias que comparamos en KEV, EPSS y SSVC: cómo priorizar vulnerabilidades explotables. Los modelos de CISA viajan, con o sin jurisdicción.
Los datos de velocidad apuntan en la misma dirección. Según el informe de caza de amenazas 2026 de CrowdStrike, recogido por Infosecurity Magazine, en el 88 % de los casos en que una vulnerabilidad publicada fue explotada durante el primer semestre de 2026, la intrusión llegó en las primeras 48 horas tras la divulgación. La explotación de fallos de día cero creció además un 42 % de 2024 a 2025.
Un caso de este mes lo ilustra. La firma alemana QUIRSO documentó la explotación de CVE-2026-59310, un salto de directorios en VMware vCenter, y contabilizó 361 direcciones IP de víctimas en 47 países; de acuerdo con The Hacker News, los primeros contactos con la infraestructura del atacante se produjeron cinco días después de que Broadcom publicase el parche. Analizamos ese fallo junto a sus dos hermanos en los tres críticos de vCenter y ESXi de VMSA-2026-0006, y la lección operativa es la que la directiva convierte en norma: para un activo expuesto con explotación activa, una semana entera ya es demasiado plazo.
Mientras el ataque se acelera, la remediación va en dirección contraria. El informe de investigaciones de brechas 2026 de Verizon, que CISA cita al justificar la directiva, estima que solo el 26 % de las vulnerabilidades del KEV se remediaron por completo en 2025, frente al 38 % del año anterior. La mediana de resolución subió a 43 días.
Y el modelo ya ha tenido su primer examen público. Aunque la obligación plena de la matriz no llega hasta diciembre, las entradas nuevas del catálogo ya traen plazos de la nueva directiva. El 18 de agosto CISA añadió al KEV cuatro fallos (uno en el servicio IKE de Windows, otro en SharePoint, el de vCenter del caso anterior y uno en macOS), todos con CVSS entre 9,1 y 9,8. Security Affairs sitúa el vencimiento del plazo para las agencias en el día 21: tres días naturales. Uno de los cuatro, el de macOS que concede root sin contraseña, también lo habíamos analizado en este blog.
Para una empresa europea el encaje es directo. NIS2 incluye la gestión y divulgación de vulnerabilidades entre las medidas de su artículo 21, y DORA obliga a las entidades financieras a gestionarlas dentro de su marco de riesgo TIC. Ninguna de las dos te da el modelo concreto. La matriz de la BOD 26-04 es un modelo publicado, gratuito y defendible ante un auditor: cuatro criterios objetivos, fuentes de datos públicas y plazos graduados que cada organización puede adaptar a su realidad.
Cómo llevar las cuatro preguntas a tu parque
Los plazos exactos importan menos que el criterio. Una adaptación razonable empieza por resolver la variable que CISA no te da hecha: la exposición. Un programa de gestión de la superficie de ataque que mantenga al día la lista de activos alcanzables desde internet convierte la primera pregunta en un dato y ahorra una discusión en cada comité.
Las otras tres preguntas se responden con fuentes públicas: la explotación confirmada, con el catálogo KEV; la automatización y el impacto, con las valoraciones de Vulnrichment; y, como señal complementaria de probabilidad mientras el CVE no aparece en el KEV, EPSS.
Con esas fuentes resueltas, toca definir los niveles propios. Sean tres días o cinco, lo que importa es que exista una regla escrita, que los plazos se deriven del riesgo de cada activo y que el nivel máximo incluya la comprobación de compromiso además del parche. En Hard2bit llevamos años defendiendo ese orden en los programas de gestión de vulnerabilidades de nuestros clientes: primero saber qué está expuesto, después decidir qué fallos justifican la prisa y solo entonces hablar de herramientas.
Queda el registro de evidencias, que es lo que sostiene todo lo anterior cuando alguien lo cuestiona: un auditor hoy, un informe posterior a un incidente mañana. Ese registro debe recoger cada decisión de priorización, la fecha de entrada del CVE en el KEV, la fecha de despliegue del parche y, en el nivel máximo, el resultado del triaje forense. El rastro resultante convierte una política en algo que se puede enseñar en una auditoría de NIS2 o de DORA sin reconstruirlo a mano cada vez.
Qué pasa si sigues con el plazo único
El coste de mantener un plazo igual para todo es pura aritmética. Si tu acuerdo de nivel de servicio trata igual un fallo interno de impacto parcial que un KEV con control total sobre un activo expuesto, tu equipo dedicará horas a fallos que pueden esperar mientras el urgente aguarda. El DBIR deja claro que la capacidad no da para todo: de un año al siguiente se remedió un porcentaje menor del KEV, con una cola que crece más deprisa de lo que los equipos remedian. Y cuando la capacidad no alcanza, repartirla mal es lo que sale caro.
Hay además un ángulo de gobierno. Bajo NIS2 la dirección responde de aprobar y supervisar las medidas de gestión de riesgos, como analizamos en NIS2 y el consejo: la responsabilidad que la dirección no puede delegar. Un consejo que aprueba un plazo de parcheo igual para todo tendrá difícil argumentar diligencia cuando el informe forense muestre que el fallo explotado llevaba semanas en la cola, por detrás de decenas de vulnerabilidades sin explotación conocida.
La métrica que debería cambiar en el próximo comité
A un comité europeo la BOD 26-04 le ofrece, como mínimo, una métrica mejor. Dejar de preguntar cuántas vulnerabilidades abiertas hay, un número que no deja de crecer, y empezar a preguntar cuántas cumplen hoy las cuatro condiciones y cuánto se tarda en cerrarlas.
El modelo no facilita la ejecución: parchear un vCenter en producción en tres días seguirá doliendo, y ninguna matriz cambia eso. Pero si, como midió CrowdStrike, casi nueve de cada diez intrusiones sobre fallos recién divulgados llegaron en menos de 48 horas, la urgencia es un recurso escaso y repartirla exige criterio. La matriz reparte ese recurso y deja el porqué por escrito: sabrás por qué ese activo se saltó la cola mientras los otros doscientos podían esperar.
Este artículo analiza una directiva de un tercer país y datos de informes públicos disponibles a fecha de publicación (agosto de 2026). La BOD 26-04 no impone obligaciones a empresas fuera del ámbito federal civil estadounidense; las referencias a NIS2 y DORA son orientativas y no constituyen asesoramiento jurídico. Verifica plazos y requisitos en las fuentes oficiales antes de adaptar tu política de parcheo.
