Microsoft actualiza CVE-2026-42903 sin parche nuevo: que significa de verdad este fallo DoS en Windows Kerberos

Microsoft ha retocado la ficha de CVE-2026-42903 sin publicar un parche nuevo. El cambio que muestra MSRC es de los que invitan a pasar página: updated an acknowledgement, informational change only. Traducido al castellano operativo: no hay nueva corrección, no se ha reabierto la evaluación técnica y no aparecen mitigaciones adicionales.

Hasta ahí, burocracia. El problema es que el componente afectado es Windows Kerberos y el impacto indicado por Microsoft es Denial of Service. Ahí la lectura superficial deja de servir. Porque un DoS en autenticación central no siempre roba datos, no siempre deja un indicador forense elegante y no siempre parece cinematográfico. Pero sí puede hacer algo bastante más molesto: impedir que el negocio arranque a las 8:00.

Ese matiz importa. Mucho. Un fallo de disponibilidad en Kerberos no se queda en “un servicio degradado”. Puede convertirse en usuarios incapaces de iniciar sesión, aplicaciones que no consiguen tickets de servicio, tareas automatizadas que fallan en cadena, VDI que no autentica, VPN corporativa que se vuelve errática y equipos de soporte recibiendo incidencias aparentemente inconexas durante 40 minutos hasta que alguien dice la palabra maldita: directorio.

Con la información pública disponible hoy no hay base para adornar CVE-2026-42903 con detalles que Microsoft no ha publicado. No sabemos, por la ficha actual de MSRC, si la explotación requiere autenticación previa, si el vector es remoto sin credenciales, si afecta a todas las ramas soportadas de Windows Server o a configuraciones concretas, ni si existe explotación activa observada por Microsoft. Ese vacío obliga a hacer periodismo y gestión de riesgo serios, no fan fiction técnico.

Lo sensato, entonces, no es ni minimizar la entrada porque “solo han cambiado un acknowledgement” ni declarar el Apocalipsis de Active Directory porque la palabra Kerberos siempre vende. Lo sensato es otra cosa: asumir que un DoS en el corazón de autenticación de Windows merece una revisión de resiliencia, no solo una revisión de parcheo.

Lo que sí sabemos, y por qué basta para activar una revisión seria

El terreno firme es corto, pero suficiente para incomodar a cualquier responsable de riesgo que prefiera mirar a otro lado. Sabemos que existe un identificador, CVE-2026-42903. Sabemos que Microsoft lo vincula a Windows Kerberos. Sabemos que el impacto descrito es denegación de servicio. Y sabemos que la actualización visible en la ficha es solo informativa. Nada más. Pero tampoco nada menos.

Ese “nada menos” es la clave. Porque si una organización necesita un exploit público, una PoC en GitHub y un parche de emergencia para empezar a revisar su dependencia de Kerberos, llega tarde al examen de resiliencia. Un comité de riesgo bien afinado no pregunta primero si el atacante puede conseguir ejecución de código. Pregunta algo más prosaico y bastante más útil: si esta pieza se degrada durante 15, 30 o 90 minutos, qué proceso de negocio se para primero y cuánto tarda alguien en darse cuenta?

Ahí es donde muchas entidades quedan retratadas. La mayoría cree conocer su dependencia de Active Directory porque sabe cuántos controladores de dominio tiene, dónde están sus sites y qué versión de Windows Server ejecutan. Eso no es gobernar la dependencia. Eso es tener inventario de infraestructura. La dependencia real está en otro sitio: aplicaciones internas con autenticación integrada, servicios IIS apoyados en cuentas de servicio, middleware Java o .NET que pide tickets, escritorios virtuales, saltos administrativos, herramientas de backup, proxies, VPN, soluciones de PAM, servidores de archivos, trabajos batch, robots de procesos, integraciones con directorios híbridos y, por supuesto, toda esa fauna legacy que sigue funcionando porque nadie se atreve a tocarla.

Cuando Kerberos falla, casi nada de eso se presenta como “fallo de Kerberos” en el minuto uno. Se presenta como síntomas sueltos. El contact center no entra en la aplicación. Un lote nocturno no termina. La oficina remota no puede mapear recursos. Un grupo de administradores pierde acceso a un jump server. Una aplicación de pólizas devuelve error de autenticación intermitente. El cierre de tesorería se retrasa porque un servicio que firma o intercambia datos deja de resolver credenciales. Y el comité de crisis, si está mal entrenado, empieza preguntando por la red, luego por la base de datos y solo al final por identidad. Demasiado tarde.

Ese es el error de fondo: tratar identidad como un dominio técnico aislado en vez de como una dependencia sistémica de continuidad. DORA no fue escrito para premiar ese autoengaño. El Reglamento (UE) 2022/2554 exige en su artículo 11 un marco de gestión del riesgo de las TIC que cubra identificación, protección, prevención, detección, respuesta y recuperación. Si una entidad no puede describir qué procesos críticos dependen de Kerberos ni cómo degradar de forma controlada cuando esa capa falla, el problema no es la CVE. El problema es el gobierno del riesgo.

Lo mismo ocurre fuera del perímetro financiero estricto. NIS2, artículo 21, obliga a aplicar medidas técnicas, operativas y organizativas apropiadas y proporcionadas, incluyendo gestión de incidentes, continuidad de negocio y seguridad de los sistemas de información. Una autenticación centralizada que puede convertirse en punto único de fallo operativo entra de lleno en ese mandato. Y si además el incidente termina afectando disponibilidad de servicios esenciales, el debate deja de ser académico.

Dicho de forma menos diplomática: no hace falta que Microsoft publique cinco páginas de detalle técnico para que una entidad seria revise si tiene demasiado negocio colgado de una pieza de autenticación que da por sentada. La ficha de MSRC ya ha dado el único empujón que hacía falta. El resto es disciplina interna.

Por qué un DoS en Kerberos importa más de lo que parece

La denegación de servicio tiene mala prensa porque suena menos sofisticada que una ejecución remota de código y menos morbosa que una exfiltración. Es un error clásico de prioridades. Para una organización compleja, dejar fuera de juego la autenticación durante media hora puede costar más, operativamente, que comprometer un host no crítico durante un día.

Kerberos no es un componente lateral. En entornos Windows con Active Directory actúa como mecanismo principal para autenticar usuarios y servicios mediante tickets. Depende de sincronización temporal, resolución correcta, disponibilidad de controladores de dominio, estado sano del KDC y una cadena de configuraciones que solo parece invisible cuando todo funciona. En cuanto deja de funcionar, aparece en todas partes a la vez.

La consecuencia práctica no es solo “los usuarios no entran”. Es una cascada de fallos de confianza entre sistemas. Si los clientes no obtienen TGT o tickets de servicio a tiempo, si el KDC se degrada, si las respuestas se vuelven erráticas o si la carga sube hasta niveles anómalos, dejan de autenticarse procesos que el negocio daba por automáticos. Tareas batch, ETL, conexiones entre aplicaciones, escritorios virtuales, acceso a compartidos, herramientas de administración remota, servicios web con autenticación integrada, agentes internos, replicaciones. El impacto es feo precisamente porque no siempre cae todo de golpe. A veces cae lo suficiente para volver el diagnóstico más lento y el daño más caro.

La paradoja regulatoria es bastante divertida, si a estas alturas todavía queda humor. Durante años, muchas organizaciones clasificaron identidad como un problema de IAM, separado de continuidad y algo por debajo de las grandes discusiones sobre recuperación tecnológica. Luego llega una vulnerabilidad de DoS en Kerberos y resulta que el cuello de botella de autenticación puede parar operaciones críticas sin tocar ni un byte de datos sensibles. De repente, el riesgo “menos sexy” pasa a ser el que más duele al negocio.

Aquí un comité de riesgo suele equivocarse de tres maneras. La primera: equiparar severidad técnica de la CVE con severidad operativa del incidente. No son lo mismo. La segunda: asumir que la redundancia de controladores de dominio resuelve por sí sola el problema, sin preguntar por saturación, localización, dependencias de red, autenticación híbrida o concentración de servicios sobre los mismos nodos. La tercera: pedir a IT una confirmación tranquilizadora del tipo “estamos parcheados” cuando ni siquiera hay parche nuevo del que hablar. Esa pregunta ya llega mal formulada.

La pregunta correcta es otra: si Kerberos se degrada mañana a las 09:15, qué servicios críticos pierden autenticación, en qué sedes, bajo qué perfiles de usuario y cuánto tiempo tardamos en detectarlo por telemetría propia, no por llamadas al service desk? Si nadie puede responder en una hora con datos, la organización ya ha aprendido algo valioso. Y bastante incómodo.

El impacto real no es abstracto: banca, seguros y administración lo notan en minutos

Hablar de disponibilidad “potencial” queda muy elegante en un informe. Hablar de operaciones concretas obliga a dejar de fingir. Un DoS en Kerberos o una degradación sostenida del servicio de autenticación tiene un patrón sectorial bastante reconocible, aunque cada arquitectura cambie los detalles.

Banca: 15 minutos malos pueden estropear una mañana entera

En banca, la autenticación central no solo habilita acceso de empleados a sus estaciones. También sostiene accesos a escritorios virtuales, aplicaciones internas de operaciones, consolas de tesorería, herramientas de fraude, portales de oficina, middleware de integración y, en no pocos casos, administración privilegiada de infraestructura que a su vez soporta servicios al cliente.

Imagina una franja de mercado de apertura con degradación de Kerberos durante 20 minutos en un entorno donde los equipos de operaciones usan VDI unido al dominio y varias aplicaciones internas se autentican por SSO. El primer síntoma puede ser una mezcla de inicios de sesión fallidos y sesiones ya abiertas que mantienen parte de la funcionalidad gracias a caché local. Eso engaña. Da la impresión de incidencia parcial. Mientras tanto, nuevas autenticaciones, reconexiones y rotaciones de sesión empiezan a fallar. Los operadores que cambian de puesto no entran. El equipo de soporte intenta elevar privilegios o acceder a consolas y se encuentra con más fricción justo cuando necesita menos.

En términos de negocio, 15 minutos de afectación pueden traducirse en una hora o más de recuperación completa. No porque el servicio técnico tarde una hora en arreglarlo, sino porque luego hay cola de usuarios, lotes reintentando, sesiones colgadas, procesos a medias y un service desk saturado. En áreas de pagos, tesorería o atención de incidencias operativas, ese desfase entre duración técnica e impacto de negocio es el detalle que los cuadros de mando suelen ocultar.

¿Clasificaría siempre eso como incidente DORA significativo? No automáticamente. Dependerá de criterios internos y de los RTS/ITS aplicables sobre clasificación y notificación. Pero si la indisponibilidad afecta un servicio crítico o importante, implica materialmente a clientes o genera degradación relevante de operaciones, la conversación ya no es “infraestructura vs seguridad”. Es gobernanza de incidente TIC, con el artículo 17 de DORA llamando a la puerta.

Seguros: el problema no es solo vender menos, es no poder tramitar

En aseguradoras, la dependencia de Active Directory y Kerberos suele ser menos vistosa desde fuera, pero igual de peligrosa por dentro. Gestión de pólizas, peritación, tramitación de siniestros, centros de atención, escritorios virtuales, accesos a carpetas compartidas con documentación, herramientas de suscripción, conectores con mediadores, aplicaciones de back-office y plataformas internas de BI pueden vivir sobre autenticación integrada o servicios que dependen de cuentas de servicio en el dominio.

Una degradación de 30 minutos a primera hora de la mañana puede generar un patrón muy concreto: los gestores no acceden a expedientes, el call center entra a medias, la documentación no se abre, las impresiones y firmas asociadas a ciertos flujos no arrancan y las tareas nocturnas de conciliación o carga que han fallado dejan inconsistencias que afloran después. El cliente quizá no vea una web pública caída. Verá algo peor: lentitud, promesas incumplidas, tiempos de respuesta más largos y expedientes que “no aparecen” porque quien debe gestionarlos no logra autenticarse o acceder al recurso dependiente.

Aquí hay un detalle incómodo para compliance. Una organización puede pasar años midiendo ciberresiliencia por número de endpoints protegidos y porcentaje de MFA, y sin embargo no haber ensayado cuánto tarda en recuperar operaciones de tramitación si el plano Kerberos se degrada. Eso no aguanta una revisión seria de resiliencia operativa. Menos aún si el negocio está sujeto a DORA o a marcos nacionales que ya aterrizan NIS2.

Administración pública: 10 minutos de caída visible, dos horas de atasco interno

La administración tiene una característica cruel: gran parte de su dependencia de autenticación está dispersa en muchísimos servicios, sedes, aplicativos históricos y perfiles de usuario distintos. Un incidente de Kerberos puede empezar con empleados que no acceden a su puesto, pero el verdadero daño aparece cuando deja de funcionar la cadena administrativa: tramitadores sin acceso, expedientes atascados, escritorios remotos inaccesibles, herramientas corporativas de gestión documental a medias y servicios presenciales o telefónicos ralentizados.

En una consejería, un ayuntamiento grande o una entidad instrumental con fuerte uso de AD, 10 minutos de indisponibilidad visible para nuevas autenticaciones pueden convertirse en 90 o 120 minutos de atasco operativo. La razón no es técnica; es organizativa. Hay reinicios, bloqueos, intentos repetidos, validaciones manuales, desplazamientos entre puestos, llamadas a soporte y una recuperación desigual entre sedes. El ciudadano percibe cola y lentitud. El equipo TIC percibe una avalancha de incidencias “diferentes” que en realidad tienen el mismo origen.

Y aquí NIS2 aprieta con especial claridad. Si la entidad entra en perímetro como esencial o importante, la combinación de gestión de incidentes, continuidad y medidas apropiadas del artículo 21 deja poco espacio para el argumento de “era solo una incidencia de directorio”. No, era una dependencia crítica mal priorizada.

La mirada que falta: qué haría mal un comité de riesgo y qué debería cambiar hoy

El error más común de un comité de riesgo no es ignorar una CVE. Es pedir el tipo de respuesta que empuja a la organización a una falsa sensación de control. La secuencia suele ser deprimente por conocida.

Primero, alguien lleva la vulnerabilidad al comité con un resumen tipo semáforo: componente afectado, severidad, exposición aparente, estado de parcheo. Segundo, el comité pregunta si hay parche, si hay explotación activa conocida y si estamos afectados. Tercero, recibe una respuesta incompleta pero tranquilizadora: “no hay nuevo parche, estamos monitorizando, no tenemos evidencia de explotación”. Cuarto, todos respiran y pasan al siguiente punto del orden del día, normalmente algo con la palabra IA o tercero crítico, que luce más moderno.

Esa dinámica falla por diseño. Reduce una cuestión de resiliencia a una casilla de vulnerabilidades. Y si el foco se queda ahí, la organización no llega a formular las preguntas que realmente importan:

• ¿Qué procesos críticos requieren autenticación Kerberos en tiempo real y no toleran degradación superior a 5, 15 o 30 minutos?
• ¿Qué servicios ya han mostrado picos de fallos de autenticación, saturación de controladores de dominio o cuellos de botella de login en el último año?
• ¿Qué cuentas de servicio, tareas programadas o integraciones dependen de SPN, delegación o tickets de servicio cuyo fallo pasaría desapercibido durante demasiado tiempo?
• ¿Qué porcentaje de nuestra detección sobre identidad depende de que un humano abra un ticket, en vez de alertas por métricas de KDC, eventos, latencia y ratio de fallos?
• ¿Hemos ensayado la recuperación operativa de una degradación de autenticación o solo tenemos un BCP que dice que existe redundancia?

Un comité de riesgo que hace bien su trabajo no pide una diapositiva sobre Active Directory. Pide un mapa de dependencia de negocio. Quiere saber qué unidad operativa deja de funcionar primero y bajo qué síntoma. Quiere umbrales de tiempo. Quiere evidencias de test. Quiere pruebas de que la segunda línea entiende cuándo una incidencia de autenticación deja de ser técnica y entra en terreno regulatorio.

¿Qué debería cambiar hoy en esa priorización? Tres cosas.

La primera: dejar de tratar identidad como subcategoría de acceso y empezar a medirla como servicio de continuidad. Si los cuadros de mando de resiliencia no tienen métricas específicas de autenticación central —éxito de logon, latencia de KDC, picos de error, capacidad de DC, tiempos de restauración de servicios dependientes— el gobierno está ciego donde más presume de control.

La segunda: revisar la concentración. Muchas entidades han centralizado VPN, VDI, aplicaciones internas, administración privilegiada y procesos batch sobre el mismo plano AD/Kerberos sin diseñar suficiente contención. Eso maximiza eficiencia en tiempos buenos y multiplica daño en tiempos malos. Muy corporativo. Muy poco resiliente.

La tercera: mover la conversación desde “tenemos redundancia” a “tenemos degradación ensayada”. No es lo mismo. Tener varios controladores de dominio no garantiza recuperación útil si la monitorización llega tarde, si los sitios están mal definidos, si la afinidad de clientes es deficiente, si hay dependencias invisibles de cuentas de servicio o si los equipos de negocio no saben operar durante el incidente.

Lo que debe mirar ahora mismo un equipo serio: no teoría, evidencias

Una actualización informativa de MSRC no obliga a activar un gabinete de crisis, pero sí justifica una revisión técnica con propósito claro. Y aquí conviene abandonar el lenguaje gaseoso. Lo útil no es “revisar Active Directory”. Lo útil es pedir evidencias concretas que permitan contestar si el entorno resistiría una degradación de Kerberos sin convertirse en caos.

Empieza por los controladores de dominio y el servicio KDC, pero no te quedes ahí. Lo primero es confirmar el universo afectado: versiones de Windows Server en controladores de dominio, presencia de sistemas cliente o servidores que dependan del flujo de autenticación Kerberos y cualquier activo especial con alto volumen de autenticaciones. Si tu CMDB no puede cruzar controladores de dominio, funciones KDC y aplicaciones críticas dependientes, ya tienes una debilidad de gobierno, no solo técnica.

Lo segundo es pedir telemetría de verdad. No una frase del tipo “no vemos nada raro”. Pide series de 30 a 90 días, si existen, sobre volumen de autenticaciones, tasa de errores por controlador de dominio, eventos relevantes del registro de seguridad o del sistema vinculados a KDC/Kerberos, consumo de CPU y memoria en DC en horas punta, latencia en sitios remotos y cualquier pico histórico coincidente con incidencias de login o de aplicaciones integradas. Si la organización no tiene esa línea base, la discusión sobre CVE-2026-42903 ya ha servido para destapar otra carencia: no sabe medir la salud operativa de su identidad central.

Lo tercero es bajar a dependencias de servicio. Necesitas una lista de aplicaciones y procesos críticos que usen autenticación integrada o cuentas de servicio en AD y saber cuáles romperían el negocio en menos de 15 minutos si fallaran nuevas autenticaciones. Eso incluye lotes, integraciones, tareas programadas, servicios web internos, VDI, VPN, PAM, herramientas de administración y cualquier proceso de cierre o atención al cliente sensible al tiempo. No hace falta una taxonomía barroca. Hace falta una tabla viva con dueño operativo y RTO realista.

Lo cuarto es revisar si existe capacidad de contención. ¿Hay segmentación entre redes de usuario, redes de administración y servicios críticos? ¿Los DC están distribuidos y correctamente utilizados por sitio? ¿Existen límites de tasa o protecciones aguas arriba en puntos donde una carga anómala podría amplificarse? ¿Se han ensayado procedimientos de aislamiento o redirección operativa? ¿Los accesos administrativos de emergencia dependen del mismo plano de autenticación que podría estar fallando? Esta última pregunta suele producir silencios muy instructivos.

Lo quinto es validar recuperación y clasificación. Si mañana se produce una degradación real, ¿quién decide si estamos ante un incidente de seguridad, de disponibilidad, de continuidad o ante las cuatro cosas a la vez? ¿Qué criterios activan escalado a gestión de crisis? ¿Qué reloj regulatorio empezaría a correr si el impacto supera ciertos umbrales? Si nadie ha unido esas piezas, la organización tiene controles, pero no tiene gobierno.

Clasificar bien importa: DORA y NIS2 no están para decorar presentaciones

El error habitual en incidentes de autenticación es dejarlos demasiado tiempo en el carril de infraestructura. Eso puede ser cómodo las primeras dos horas y peligrosísimo después. Tanto DORA como NIS2 obligan a pensar antes en impacto y servicios que en el nombre del componente afectado.

En DORA, el punto de partida es el marco de gestión del riesgo TIC del artículo 11 y la disciplina de gestión, clasificación y notificación de incidentes del artículo 17. La clasificación de un incidente relacionado con las TIC no depende de si el fallo fue causado por una vulnerabilidad muy mediática o por algo tan poco glamuroso como una saturación de Kerberos. Depende del impacto sobre servicios, clientes, operaciones, integridad de datos, disponibilidad y alcance. Los detalles finos se aterrizan mediante normas técnicas y criterios internos, pero la lógica es clara: si la autenticación central cae y eso compromete un servicio crítico o importante, el tratamiento debe escalar con rapidez.

En NIS2 el principio es parecido, con otro lenguaje. El artículo 21 exige medidas apropiadas para prevenir, detectar, responder y recuperarse. Y los regímenes de notificación derivados por la directiva y su transposición nacional obligan a distinguir incidentes significativos según el efecto sobre la prestación de servicios y otros factores de severidad. La disponibilidad no es una nota al pie. Es una dimensión central.

Esto tiene una implicación práctica bastante menos obvia de lo que debería. La clasificación no puede esperar a que el equipo de infraestructura “termine de diagnosticar”. Si un banco, aseguradora o entidad pública tarda tres horas en reconocer que el problema de logon está afectando un proceso crítico, puede haber consumido la ventana útil de reacción ejecutiva. La primera clasificación tiene que ser provisional pero operativa, con criterios de negocio predefinidos.

Un esquema razonable para un incidente de Kerberos/AD en entornos regulados debería mirar al menos cinco variables:

• Duración efectiva de la degradación: no solo tiempo técnico del fallo, sino tiempo hasta recuperación operativa de servicios dependientes.
• Alcance: número de usuarios, sedes, unidades, sistemas o servicios afectados.
• Criticidad del servicio impactado: si afecta pagos, tramitación esencial, atención al cliente, operaciones de mercado, siniestros, administración tributaria u otros servicios con obligación fuerte de continuidad.
• Capacidad de workaround: si existe operación manual o degradada y cuánto tiempo aguanta antes de generar incumplimiento o daño material.
• Evidencia de causa maliciosa o explotación de vulnerabilidad: útil para investigación y reporte, pero no condición previa para activar gobierno de incidente.

La trampa es pensar que sin prueba de explotación la clasificación puede esperar. No. Para DORA y NIS2, una indisponibilidad material puede ser regulatoriamente relevante aunque la causa raíz tarde en cerrarse.

Metodología accionable: qué hacer en 30, 60 y 90 días

Si esta CVE sirve para algo más que alimentar un cuadro de mando, debería servir para forzar un plan corto, con entregables verificables. No hablo de una transformación de identidad a dos años. Hablo de 90 días para reducir incertidumbre y mejorar capacidad de respuesta.

Primeros 30 días: visibilidad, criticidad y dueños

En el primer mes el objetivo no es rediseñar arquitectura. Es saber qué depende de Kerberos y qué dolería de verdad si falla.

Pide a IT y a seguridad estas evidencias concretas:

• Inventario de controladores de dominio, versiones de sistema operativo, roles relevantes y localización por sitio.
• Mapa de aplicaciones y servicios críticos que usan autenticación integrada, cuentas de servicio en AD o dependencias directas de Kerberos.
• Listado de cuentas de servicio críticas, SPN registrados y servicios que quedarían afectados si no se emiten tickets con normalidad.
• Telemetría básica de 30 días: volumen de autenticaciones, errores por DC, eventos KDC/Kerberos relevantes, uso de CPU/memoria y alertas históricas asociadas a login.
• Inventario de VDI, VPN, PAM, jump servers y accesos administrativos que dependan del mismo plano de autenticación.
• Clasificación preliminar de procesos de negocio afectados en ventanas de 5, 15, 30 y 60 minutos de degradación.

Con eso encima de la mesa, el entregable de 30 días debe ser un mapa simple pero incómodo: procesos críticos, dependencia Kerberos/AD, RTO asumido, workaround disponible y responsable de negocio. Si el documento termina siendo una lista técnica de servidores, no has avanzado nada.

En paralelo, define criterios provisionales de escalado. Por ejemplo: si la tasa de autenticaciones fallidas supera X veces la línea base durante Y minutos en dos o más servicios críticos, se activa puente de incidente con participación de negocio y segunda línea de riesgo. Ajusta X e Y a tu entorno, pero pon números. Sin números, todo el mundo discute; nadie decide.

De 30 a 60 días: pruebas, contención y clasificación regulatoria

El segundo tramo debe convertir visibilidad en capacidad de respuesta. Ya sabes qué depende de Kerberos. Ahora toca comprobar si la organización puede aguantar una degradación real sin improvisar de forma caótica.

Aquí las evidencias que debes pedir cambian:

• Resultados de pruebas controladas o simulaciones de degradación de autenticación en entorno preproducción o laboratorio representativo.
• Verificación de afinidad por sitio y capacidad efectiva de DC, incluyendo latencia y comportamiento bajo carga.
• Revisión de cuentas de servicio con privilegios elevados, configuraciones de delegación y SPN huérfanos o inconsistentes.
• Procedimientos de acceso administrativo de emergencia que no dependan enteramente del mismo plano afectado.
• Runbooks de diagnóstico rápido para distinguir problema de Kerberos/KDC, DNS, tiempo, red o aplicación.
• Matriz provisional DORA/NIS2 para clasificar incidentes de autenticación según duración, alcance y criticidad.

Este es el momento de sentar a seguridad, infraestructura, continuidad y cumplimiento en la misma mesa. Sí, juntos. Nadie disfruta, pero funciona. El objetivo es acordar umbrales de clasificación. ¿Cuándo una degradación de autenticación pasa de incidente técnico a incidente regulatoriamente relevante?

Una matriz práctica puede usar tres preguntas encadenadas:

1. ¿La degradación afecta un servicio crítico o importante definido por la entidad?
2. ¿Supera el tiempo máximo tolerable o bloquea operación sin workaround razonable?
3. ¿Tiene alcance material sobre clientes, empleados clave, sedes o procesos regulados?

Si dos de las tres respuestas son sí, el incidente debería tratarse desde el inicio como candidato a clasificación formal bajo DORA o NIS2, aunque la causa raíz aún no esté cerrada. Eso evita la parálisis clásica de esperar “más datos” mientras el negocio ya está sufriendo.

De 60 a 90 días: remediación priorizada y gobierno de verdad

En el tercer tramo ya no vale esconderse detrás del diagnóstico. Toca ejecutar mejoras concretas y medibles.

Las prioridades razonables son estas:

• Reducir puntos de concentración excesiva sobre el mismo plano AD/Kerberos, empezando por VDI, VPN y accesos administrativos.
• Corregir cuentas de servicio mal gestionadas, SPN duplicados u obsoletos y configuraciones de delegación innecesariamente amplias.
• Mejorar monitorización con umbrales específicos de autenticación y alertas por desviación sobre línea base.
• Ensayar un escenario de degradación con negocio: qué sistemas fallan primero, quién declara incidente, qué workaround se activa y cuánto tarda la recuperación útil.
• Aprobar en comité de riesgo un cuadro de mando con métricas de identidad como servicio crítico, no como simple dominio técnico.

El entregable de 90 días no debería ser una presentación brillante. Debería ser una decisión de priorización firmada: qué dependencias se corrigen primero, qué umbrales activan escalado ejecutivo, qué mejoras de monitorización se implantan y qué escenario se volverá a ensayar en los siguientes seis meses.

Qué evidencias concretas deberías pedir hoy mismo a IT

Si eres CISO, responsable de resiliencia, auditor interno o segunda línea de riesgo, no pidas “un informe sobre Kerberos”. Pide pruebas. La diferencia entre ambas cosas es básicamente la diferencia entre gobernar y coleccionar PDFs.

Estas son las evidencias más útiles para una revisión inmediata:

• Estado de activos: lista de DC, sistemas relevantes y versiones soportadas, con fecha de último parcheo y ventanas pendientes.
• Salud operativa: métricas de CPU, memoria, latencia y carga en controladores de dominio durante horas punta.
• Eventos y errores: registros de eventos relacionados con Kerberos/KDC y tendencias de fallos de autenticación por día y por servicio.
• Dependencias críticas: aplicaciones, tareas batch, VDI, VPN, PAM y servicios core que no toleren más de 15 o 30 minutos de degradación.
• Cuentas de servicio y SPN: inventario de cuentas privilegiadas, SPN críticos, duplicados detectados, delegaciones configuradas y excepciones documentadas.
• Accesos de emergencia: evidencia de mecanismos de administración alternativos o de contingencia probados.
• Pruebas de recuperación: fecha y resultados del último test o simulación de incidente que afectara identidad, autenticación o directorio.
• Clasificación y escalado: procedimiento aprobado para elevar una incidencia de autenticación a incidente TIC con posible impacto DORA/NIS2.

Si alguna de estas pruebas no existe, no lo disfraces. Regístralo como hallazgo. Una organización madura no presume de omnisciencia; sabe documentar lo que todavía no controla.

Lo que no conviene hacer ahora: ni pánico ni placebo

Hay dos respuestas inútiles a una CVE como esta. La primera es el alarmismo automático: convocar reuniones grandilocuentes, hablar de colapso de AD y empezar a desplegar cambios improvisados sin haber identificado dependencias reales. La segunda es el placebo corporativo: asumir que, como no hay parche nuevo y Microsoft no ha añadido detalle técnico, basta con “seguir monitorizando”.

La primera opción crea ruido y errores. La segunda conserva la comodidad. Ninguna mejora resiliencia.

Tampoco conviene caer en la trampa habitual de sobreexplicar Active Directory para evitar decidir. A estas alturas no hace falta otro documento describiendo cómo funcionan tickets TGT o el rol del KDC a nivel conceptual. Lo que hace falta es una decisión de gestión: qué parte de la dependencia de autenticación central es intolerable para el negocio y qué controles se van a reforzar ya. Si la conversación sigue orbitando teoría, alguien está comprando tiempo, no reduciendo riesgo.

La primera decisión concreta que deberías tomar sobre Kerberos y AD

Si el lector sale de aquí solo con contexto, hemos perdido el tiempo. Así que vamos a lo medible.

La recomendación más útil y menos glamurosa es esta: en los próximos 10 días revisa y valida los 20 servicios, aplicaciones o procesos con mayor impacto de negocio que dependan de Kerberos, y comprueba tres cosas para cada uno: método exacto de autenticación, cuenta de servicio o SPN asociado, y tiempo máximo tolerable de degradación antes de afectar operación.

No 200 servicios. No “todo Active Directory”. Los 20 que más daño harían. Si tu organización es más pequeña, serán 10. Si es enorme, quizá 30. Pero pon un número, un plazo y un dueño.

¿Qué revisar primero dentro de Kerberos/AD? Este orden funciona porque reduce incertidumbre rápido:

1. Cuentas de servicio críticas y sus SPN: identifica duplicados, obsolescencia, privilegios excesivos y dependencias no documentadas.
2. Controladores de dominio que soportan mayor carga: valida línea base de autenticaciones, picos, capacidad y alertas.
3. VDI, VPN y accesos administrativos: comprueba si concentran demasiada dependencia sobre el mismo plano de autenticación.
4. Procesos batch y cierres operativos: confirma qué falla si no se emiten tickets con normalidad durante 15-30 minutos.
5. Runbook de clasificación: define cuándo una incidencia de login deja de ser “tema de sistemas” y activa gobierno DORA/NIS2.

El criterio de éxito también debe ser concreto. Al cierre de esa revisión, deberías poder responder, con evidencia, a cuatro preguntas:

• ¿Qué procesos críticos se paran primero si Kerberos se degrada?
• ¿Qué señales técnicas nos avisarían antes de que lo haga el negocio?
• ¿Qué workaround real existe y cuánto aguanta?
• ¿Cuándo clasificaríamos el incidente como relevante bajo DORA o NIS2?

Si hoy no puedes responderlas, CVE-2026-42903 ya te ha dado una información muy valiosa aunque Microsoft no haya publicado ni una línea técnica adicional: tu riesgo no está en la nota de acknowledgement. Está en la dependencia que todavía no has medido.

Y eso sí tiene remedio. Pero no empieza con otra presentación sobre identidad. Empieza con una orden simple: traedme en 10 días el mapa de dependencias críticas de Kerberos, las cuentas de servicio asociadas y el umbral a partir del cual esto deja de ser una incidencia técnica y pasa a ser un incidente de resiliencia. Lo demás es decoración.