Actualizar sin romper: cuando la seguridad nueva choca con los equipos de siempre

c_actualizaciones_legacy sobre 2026
octubre 16, 2026

Una actualización de seguridad de Windows puede dejar de un día para otro sin acceso a una carpeta compartida que siempre había funcionado. La tentación es desactivar la protección nueva para seguir trabajando, pero casi nunca es la solución: lo que suele hacer falta es ajustar los sistemas para que vuelvan a entenderse sin perder seguridad.

Es lo que ha ocurrido este mes con la actualización acumulativa de octubre de 2026 (KB5127648). En algunos equipos, Windows empezó a rechazar la conexión a un servidor de archivos con un mensaje poco aclaratorio: «la autenticación NTLM está deshabilitada». No había ningún fallo en el servidor ni en la red. Simplemente, el equipo había endurecido su forma de identificarse y el otro extremo no podía usar la alternativa más moderna.

Equipos de distintas generaciones en la misma red

En una pyme es habitual que convivan ordenadores recién comprados con un servidor de archivos de hace varios años, una impresora que nadie quiere cambiar porque funciona, una aplicación de gestión que solo corre en una versión concreta de Windows o un equipo de taller que lleva una década controlando una máquina. Cada uno se instaló en su momento con lo que había, y durante años han hablado entre sí sin problemas.

El problema aparece cuando una de las partes se actualiza y la otra no. Los fabricantes van retirando poco a poco los métodos de autenticación y cifrado antiguos, porque son los que aprovechan los ataques, y cada actualización aprieta un poco más. El equipo nuevo deja de aceptar lo que el antiguo sigue ofreciendo, y la conexión que funcionaba ayer deja de hacerlo hoy, sin que nadie haya tocado nada.

No es un fallo de la actualización. Es la consecuencia lógica de tener en la misma red sistemas que se mueven a ritmos distintos.

La reacción fácil y la correcta

Cuando algo deja de funcionar tras una actualización, lo más rápido es buscar el ajuste que devuelve el comportamiento anterior: desinstalar el parche, desactivar la protección o relajar la seguridad del equipo. Funciona, y por eso es tentador. Pero deja el equipo expuesto justo a aquello de lo que la actualización pretendía protegerlo, y suele quedarse así porque nadie vuelve a acordarse.

En el caso de octubre, ese atajo existía: un valor del registro devolvía el comportamiento antiguo a todo el equipo. Servía para confirmar la causa, pero no como solución. La salida correcta pasaba por activar una protección que estaba apagada, Credential Guard, y con ella la conexión volvió a funcionar sin rebajar nada. Es decir, el problema no se resolvió con menos seguridad, sino con más.

No siempre es así de limpio. A veces el equipo antiguo no admite nada mejor y hay que aceptar una excepción. Cuando ocurre, conviene que sea una decisión consciente: limitada a ese equipo, documentada y con fecha de revisión, no un ajuste olvidado.

Antes de la próxima actualización

No hace falta un gran proyecto para que una actualización no pille por sorpresa. Bastan unos hábitos que, en la práctica, ahorran muchas mañanas perdidas.

El primero es saber qué hay en la red: qué equipos, qué versión tienen y de qué dependen. Una lista sencilla, actualizada, permite anticipar qué puede romperse cuando llega un cambio como el de octubre. El segundo es no actualizar todo a la vez. Probar primero en uno o dos equipos, durante unos días, deja ver los problemas antes de que afecten a toda la oficina.

El tercero es tener un plan para los equipos que se han quedado atrás. Algunos se pueden actualizar; otros, conviene aislarlos en su propio segmento de red para que su debilidad no afecte al resto, y otros habrá que sustituirlos. Lo que no funciona es ignorarlos hasta que fallan. Y, por último, revisar de vez en cuando las protecciones de los equipos nuevos: no es raro encontrar funciones de seguridad desactivadas hace tiempo por una incompatibilidad que ya no existe.

Lo que viene

El cambio de octubre es solo un paso. Microsoft ha anunciado que su objetivo es desactivar NTLM por defecto en las próximas versiones de Windows, y otros fabricantes siguen el mismo camino con los protocolos antiguos. Habrá más actualizaciones que corten conexiones que hoy funcionan, y lo razonable es asumirlo y prepararse, no retrasar las actualizaciones para evitarlo.

Mantener los equipos al día y, a la vez, comunicados entre sí de forma segura no es incompatible. Requiere conocer lo que se tiene, probar antes de desplegar y tomar decisiones conscientes con lo que se queda atrás.

Para quien quiera el detalle técnico del caso de octubre, hay un diagnóstico paso a paso y un script de comprobación de solo lectura en GitHub. La referencia oficial de Microsoft es la KB5066470.