La actualización de abril de 2026 pone en riesgo el arranque de BitLocker en Windows Server 2025

Autor: Publicada 4 min de lectura 287 lecturas

Las imágenes de este artículo han sido generadas con inteligencia artificial. Cómo publicamos

Microsoft ha solucionado un problema que, tras la actualización de seguridad de abril de 2026, provocaba que algunos servidores con Windows Server 2025 arrancaran en la pantalla de recuperación de BitLocker y pidieran la clave de recuperación al primer reinicio. Aunque el fenómeno afectaba sobre todo a entornos corporativos con configuraciones de BitLocker y TPM poco recomendadas, el episodio vuelve a poner sobre la mesa riesgos operativos reales para infraestructuras críticas cuando las actualizaciones interactúan con validaciones de plataforma y firmas de arranque.

En términos técnicos, el fallo ocurría en equipos que cumplían una serie de condiciones muy concretas: BitLocker activado en la unidad del sistema operativo, la directiva de grupo "Configure TPM platform validation profile for native UEFI firmware configurations" configurada incluyendo el PCR7, la herramienta de información del sistema (msinfo32.exe) mostrando que el “Secure Boot State PCR7 Binding” era "Not Possible", la presencia del certificado Windows UEFI CA 2023 en la DB de Secure Boot y que el equipo no estuviera ya usando el Windows Boot Manager firmado con la cadena 2023. Cuando se daban todas esas circunstancias, la actualización automática del gestor de arranque podía disparar la recuperación de BitLocker al considerar que el estado de la plataforma había cambiado.

La actualización de abril de 2026 pone en riesgo el arranque de BitLocker en Windows Server 2025
Imagen generada con IA.

Microsoft distribuyó correcciones en junio de 2026: la actualización para Windows Server 2025 se publica bajo KB5094125 y la correspondiente para Windows 11 23H2 bajo KB5093998. Las notas oficiales explican además que los dispositivos impactados registrarán el evento 1032 en el registro de sistema durante la instalación de actualizaciones, una pista útil para identificar equipos que han intentado instalar el gestor de arranque 2023-signed y hubieran forzado la recuperación.

Para administradores que aún no pueden desplegar estos parches, Microsoft recomienda dos vías de mitigación: quitar la configuración de la directiva de grupo problemática antes de instalar las actualizaciones o aplicar un Known Issue Rollback (KIR) que evita el cambio automático al Windows Boot Manager firmado en 2023. Las instrucciones y la descripción de KIRs están disponibles en la documentación de Microsoft sobre Known Issue Rollbacks, y conviene planificarlas en ventanas de mantenimiento controladas para evitar sorpresas.

Más allá del parche inmediato, hay varias acciones prácticas que convierten esta lección en una mejora sostenible de la postura de seguridad y operación: verificar que las claves de recuperación de BitLocker estén correctamente almacenadas y accesibles (por ejemplo, en Active Directory o Azure AD), validar en laboratorio cualquier cambio de política TPM/UEFI antes de rodarlo en producción y monitorizar eventos relevantes como el ID 1032 y registros relacionados con BitLocker y Secure Boot durante los despliegues.

Para problemas de diagnóstico, inspeccione msinfo32 para confirmar el estado de PCR7 y Secure Boot, revise la DB de Secure Boot para comprobar la presencia del certificado Windows UEFI CA 2023 y use las directivas de grupo para localizar la configuración "Configure TPM platform validation profile for native UEFI firmware configurations". Si un equipo entra en la recuperación de BitLocker, la entrada única de la clave suele restaurar el arranque; sin embargo, en servidores remotos o en nubes privadas esto puede implicar downtime significativo si no hay personal para introducir la clave físicamente.

La actualización de abril de 2026 pone en riesgo el arranque de BitLocker en Windows Server 2025
Imagen generada con IA.

Es importante subrayar que, según Microsoft, la incidencia tiene un alcance limitado y es menos probable en dispositivos personales; sin embargo, los entornos empresariales con políticas avanzadas de TPM y arranque seguro son los más expuestos. Para equipos de operaciones y seguridad esto significa ajustar procedimientos de despliegue de parches: priorizar pruebas en staging, preparar acceso a claves de recuperación y coordinar con operaciones para ventanas de mantenimiento.

Finalmente, conviene adoptar una práctica preventiva: documentar y automatizar la gestión y copia de seguridad de claves de BitLocker, auditar cambios en políticas de TPM y Secure Boot y mantener un catálogo de controladores y firmas de arranque aprobadas. La interacción entre parches, firmware y políticas de seguridad es un vector recurrente de riesgo operativo; aplicar controles de validación y recuperación probados reduce la probabilidad de interrupciones inesperadas tras actualizaciones críticas.

Para más información técnica y guías de Microsoft sobre BitLocker y su administración puede consultarse la documentación oficial en BitLocker overview, además de las páginas de soporte de las actualizaciones señaladas KB5094125 y KB5093998.

Cobertura

Relacionadas

Mas noticias del mismo tema.