El último de los cuatro certificados con los que Microsoft firmó el arranque de prácticamente todos los PC con Windows vendidos desde 2012, ha vencido. La compañía publicó tres días después que esa caducidad no impide encender el equipo ni iniciar Windows, y ahí está la parte que se malinterpreta: el sistema sigue funcionando, pero deja de recibir mejoras en la primera fase del arranque, la que decide qué código puede ejecutarse antes del sistema operativo.
Los certificados afectados son Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011 y Microsoft Windows Production PCA 2011, sustituidos por las autoridades de 2023 que la compañía enumera en su documentación. Afecta a Windows 10, Windows 11 y Windows Server, incluidas las ramas LTSC, y a cualquier sistema que comparta firmware con Windows, Linux incluido. Los Copilot+ de 2025 ya salieron con las claves nuevas y quedan fuera.
Lo que se pierde no es el arranque, es el margen: sin el certificado de 2023 en la base de datos del firmware, el equipo no acepta ni un gestor de arranque nuevo ni una lista de revocaciones actualizada. Si mañana aparece un cargador de arranque firmado y comprometido, ese equipo no tendrá forma de dejar de confiar en él. La actualización exige tocar firmware, KEK y DB, y el plazo de las dos primeras venció en junio.
¿Qué caducó y con qué se sustituye?
Microsoft fijó el calendario en junio de 2025, en un blog para administradores que pedía revisar el firmware del fabricante con más de un año de antelación. Los cuatro certificados de 2011 se relevan por cuatro de 2023 y no caducan el mismo día.
| Certificado de 2011 |
Caducó |
Sustituto de 2023 |
| Microsoft Corporation KEK CA 2011 |
24 de junio de 2026 |
Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 |
27 de junio de 2026 |
Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 |
19 de octubre de 2026 |
Windows UEFI CA 2023 |
El reparto importa porque un equipo puede tener el certificado de 2023 en el DB y seguir sin aceptar revocaciones si su KEK es la vieja. La KEK firma las actualizaciones de las bases de datos, el DB guarda las firmas aceptadas y el DBX las revocadas. Microsoft separó además la firma de cargadores de terceros de la de option ROM, para que un servidor no tenga que confiar en cualquier cargador ajeno por confiar en una tarjeta de red.
Sin certificado, arranca, pero no es seguro
El certificado caducado sigue inscrito en la base de datos de firmas del firmware, y mientras siga ahí el equipo sigue aceptando lo que ese certificado firmó. La fecha de caducidad no borra la confianza ya otorgada: limita la posibilidad de firmar binarios nuevos con esa clave. Por eso un PC que arrancaba el 18 de octubre sigue arrancando el 20, con el mismo cargador y la misma firma.
El problema aparece cuando hace falta algo nuevo. Un parche del gestor de arranque, una actualización de la base de datos o una revocación urgente llegan firmados con la autoridad de 2023.
Ahí se cierra la puerta: Microsoft documenta que esos equipos dejan de recibir protecciones nuevas para el proceso de arranque, incluidas las actualizaciones del gestor de arranque, de las bases de datos de Secure Boot y de las listas de revocación, además de las mitigaciones para vulnerabilidades descubiertas en esa fase. También se resienten escenarios que dependen de esa confianza, como BitLocker endurecido o los cargadores de terceros.
Un caso cercano
El caso tiene un pariente cercano en la capa TLS, donde la confianza también se apoya en un puñado de autoridades y un certificado mal emitido obliga a revocar en horas, como ocurrió con los ocho intermedios de eMudhra que firmaban con claves de un solo byte. La diferencia es que allí la revocación viajó por el navegador; aquí depende de que el firmware pueda recibirla.
Microsoft publicó el 22 de octubre un aviso nuevo: el último gestor de arranque firmado con el certificado de 2011 queda congelado en todas las ramas de Windows con soporte, sin más parches de código ni correcciones de seguridad.
Los futuros parches del arranque se firmarán solo con la autoridad de 2023, y las próximas versiones mayores de Windows exigirán ese certificado en el DB. El medio de instalación bloqueará la instalación en equipos que no lo tengan.
Linux también cambia de clave, con el shim de por medio
El shim, el pequeño binario que arranca el cargador de una distribución de Linux y que Microsoft firma para que el firmware lo acepte, salía de la misma autoridad de 2011. Desde octubre de 2025 Microsoft firma cada shim con las dos claves, la vieja y la nueva, y desde junio de 2026 solo puede firmar con la de 2023. Esa transición deja a los equipos con el DB antiguo ante una elección incómoda.
Red Hat publicó shims firmados con ambas claves para RHEL 9.8 y 10.2, y llevó la versión doblemente firmada a RHEL 8 en junio de 2026. Su guía para entornos RHEL advierte de que un shim futuro, firmado solo con la clave de 2023, no arrancará si el firmware no tiene ese certificado en el DB, y que quien no pueda actualizarlo tendrá que seguir con un shim vulnerable o desactivar el arranque seguro.
La advertencia que más se salta la intuición de limpiar a fondo es la contraria: no hay que revocar el certificado de 2011. Si entra en el DBX, el shim firmado con las dos claves deja de arrancar, porque una de sus firmas ya no vale.
Lo mismo pasa con los option ROM firmados en 2011, que dejarían de ejecutarse. Red Hat añadió una utilidad, sbchooser, dentro del paquete efivar, para no instalar un shim que el firmware no pueda validar.
Cada proyecto lleva su propio calendario de parches, y no siempre coincide con el del firmware: OpenBSD 8.0 llegó con soporte para Intel Arc y tres parches de seguridad, mientras las distribuciones con firmware sin mantenimiento dependen de una actualización de UEFI que puede no existir. Para esas máquinas, fwupd es la vía documentada para actualizar el DB.
¿Qué toca hacer en un parque que no se actualizó?
El orden de los pasos importa tanto como la actualización. Microsoft insiste en empezar por el firmware del fabricante y en dejar que Windows Update reparta los certificados después, porque es el firmware quien guarda las bases de datos donde se inscriben las claves nuevas. Para flotas gestionadas hay scripts de inventario y una guía de despliegue gradual, y el trabajo real se reduce a cinco comprobaciones.
- Firmware del fabricante primero, porque sin una UEFI que admita los certificados de 2023 el resto de pasos no sirve.
- Estado del DB en cada equipo, con la aplicación Seguridad de Windows en Windows y con fwupd en Linux.
- Copia de la clave de recuperación de BitLocker antes de tocar la cadena de arranque, ya que una actualización de firmware puede pedirla.
- Políticas WDAC y herramientas de integración ancladas en PCA 2011, capaces de bloquear binarios actualizados bien firmados.
- Inventario de máquinas virtuales, porque las de Hyper-V de segunda generación reciben los certificados por actualización acumulativa, las de Azure por servicio de plataforma y las de VMware dependen del host y de la versión de hardware.
Ninguno de esos pasos es exótico, y ese es justo el problema: son tareas de inventario y de mantenimiento que compiten con el resto del trabajo de un administrador y que no dan señales visibles cuando se aplazan.
Una deuda que solo se paga cuando hay que revocar
La caducidad de 2011 no ha roto nada visible, y esa es la parte incómoda. Un equipo sin los certificados de 2023 arranca, instala las actualizaciones mensuales y no muestra ningún aviso, mientras acumula una deuda que solo se paga el día en que aparece una vulnerabilidad en el arranque y hace falta revocar un cargador comprometido. Para entonces la ventana ya está cerrada.
La lección se repite en cada capa de la cadena de confianza, del TLS al firmware: los certificados caducan, los algoritmos se jubilan y la migración siempre llega tarde a los equipos que nadie inventaría. Microsoft publicó el calendario con más de un año de margen y el último plazo venció el 19 de octubre. Quien ya actualizó no notará nada; el resto lo notará de golpe.
